From jira-events at jboss.com  Fri Sep  1 03:21:18 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Fri, 1 Sep 2006 03:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-595) Fix the spring http
 performance tests.
In-Reply-To: <15640238.1156986823869.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4297408.1157095278193.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-595?page=all ]

Ron Sigal closed JBREM-595.
---------------------------

    Resolution: Done

The spring_http test still failed randomly after the changes that allowed the spring_rmi test to work.  Some clients were failing with "address in use" BindExceptions when they tried to call a method on the server proxy.  It looks like machine (Windows) was running out of available ports, even when the MaxUserPort tcp parameter was set to 64000.  The failure was corrected by putting method invocations in a loop that runs until the invocation succeeds.

> Fix the spring http performance tests.
> --------------------------------------
>
>                 Key: JBREM-595
>                 URL: http://jira.jboss.com/jira/browse/JBREM-595
>             Project: JBoss Remoting
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.Beta1 (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The changes made for the spring rmi performance test need to be applied to the spring http tests. See JBREM-592 for more information.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:39:18 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 03:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-293) Support for more
	system properties
Message-ID: <26071221.1157096358240.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support for more system properties
----------------------------------

                 Key: JGRP-293
                 URL: http://jira.jboss.com/jira/browse/JGRP-293
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Optional
             Fix For: 2.4


${jboss.mcast.ip.ttl:2}

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:45:17 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Fri, 1 Sep 2006 03:45:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-358) Look into WTP
 Facet's as a
 unified api for handling "lib" and "project" configuration
Message-ID: <23472544.1157096717802.JavaMail.jira@cloud.prod.atl2.jboss.com>

Look into WTP Facet's as a unified api for handling "lib" and "project" configuration
-------------------------------------------------------------------------------------

                 Key: JBIDE-358
                 URL: http://jira.jboss.com/jira/browse/JBIDE-358
             Project: JBoss IDE
          Issue Type: Task
    Affects Versions: 2.0.0.Beta1
            Reporter: Max Andersen
         Assigned To: Marshall Culpepper
             Fix For: 2.0.0.Beta2




-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:51:18 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 1 Sep 2006 03:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18269889.1157097078124.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-79?page=all ]

Alexey Loubyansky reassigned JBXB-79:
-------------------------------------

    Assignee: Alexey Loubyansky

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:53:17 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 1 Sep 2006 03:53:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24557531.1157097197066.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBXB-79?page=comments#action_12342577 ] 
            
Alexey Loubyansky commented on JBXB-79:
---------------------------------------

The problem occurs during unmarshalling. An instance of the class is created and then array items are appended to the array. The fix would be to ignore the initialization you do in the class initializer and just set the unmarshalled value. That's what I meant.

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:59:16 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 03:59:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-294) Introduce system
 property to
 preserve backwards compatibility of Util.object{To,From}ByteBuffer()
Message-ID: <3922788.1157097556700.JavaMail.jira@cloud.prod.atl2.jboss.com>

Introduce system property to preserve backwards compatibility of Util.object{To,From}ByteBuffer()
-------------------------------------------------------------------------------------------------

                 Key: JGRP-294
                 URL: http://jira.jboss.com/jira/browse/JGRP-294
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


Because of the HAPartitionImpl marshalling issue we found in 4.0.x last
night, 2.4 is not going to work in 4.0.2 (or any 4.0 before 4.0.5.GA).

A workaround for this is to check a system property in a static
initializer in Util. If "compatibility mode" or whatever, fall back to
the old Util.objectTo/FromByteBuffer impl. Users of old AS releases
would have to set this property to use 2.4 or higher.

But, it seems I have system properties on the brain these days; its
starting to look like a golden hammer, so proceed with caution ;)

BTW, the JIRA to ensure this isn't an issue for 4.0.5.GA is
http://jira.jboss.com/jira/browse/JBAS-3593.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 05:47:20 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 05:47:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-294) Introduce system
 property to
 preserve backwards compatibility of Util.object{To,From}ByteBuffer()
In-Reply-To: <3922788.1157097556700.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5662868.1157104040545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-294?page=all ]

Bela Ban resolved JGRP-294.
---------------------------

    Resolution: Done

> Introduce system property to preserve backwards compatibility of Util.object{To,From}ByteBuffer()
> -------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-294
>                 URL: http://jira.jboss.com/jira/browse/JGRP-294
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Because of the HAPartitionImpl marshalling issue we found in 4.0.x last
> night, 2.4 is not going to work in 4.0.2 (or any 4.0 before 4.0.5.GA).
> A workaround for this is to check a system property in a static
> initializer in Util. If "compatibility mode" or whatever, fall back to
> the old Util.objectTo/FromByteBuffer impl. Users of old AS releases
> would have to set this property to use 2.4 or higher.
> But, it seems I have system properties on the brain these days; its
> starting to look like a golden hammer, so proceed with caution ;)
> BTW, the JIRA to ensure this isn't an issue for 4.0.5.GA is
> http://jira.jboss.com/jira/browse/JBAS-3593.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 06:27:21 2006
From: jira-events at jboss.com (Stefan Kassal (JIRA))
Date: Fri, 1 Sep 2006 06:27:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-295) DistributedHashtable
 and ChannelFactory with XML config file
Message-ID: <32773016.1157106441257.JavaMail.jira@cloud.prod.atl2.jboss.com>

DistributedHashtable and ChannelFactory with XML config file
------------------------------------------------------------

                 Key: JGRP-295
                 URL: http://jira.jboss.com/jira/browse/JGRP-295
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4
            Reporter: Stefan Kassal
         Assigned To: Bela Ban


I think I have found an issue with DistributedHashtables (jgroups 2.4CR2)
I have a XML file containing the protocol stack and create a ChannelFactory with that file.

ChannelFactory  factory=new JChannelFactory(new File(configFilePathM));
	
The DistributedHashtable is created with

DistributedHashtable distHashM = new DistributedHashtable(distChannelNameM,factory,channelProps,true,TIMEOUT);
	
The problem is that the constructor of the DistributedHashtable class which I want to use uses the following:

channel=factory != null ? factory.createChannel(properties) : new JChannel(properties);
	
That means it always tries to uses the properties to create the channel and you cannot force it to use the configuration of the factory.
This could be solved in a way that you check if the properties is null and if it is you call  factory.createChannel()

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 06:55:44 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Fri, 1 Sep 2006 06:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3595) Tomcat allows http
 access with transport guarantie CONFIDENTIAL
Message-ID: <5034484.1157108144114.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tomcat allows http access with transport guarantie CONFIDENTIAL
---------------------------------------------------------------

                 Key: JBAS-3595
                 URL: http://jira.jboss.com/jira/browse/JBAS-3595
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Thomas Diesler
             Fix For: JBossAS-5.0.0.Beta


The generated web.xml contains CONFIDENTIAL. Access via http:// should be denied.
This woks in Branch_4_0

/home/tdiesler/svn/jbossws/trunk/src/test
[tdiesler at tdvaio test]$ ant -Dtest=org.jboss.test.ws.samples.secureejb.SecureEJBTestCase one-test

one-test:
    [junit] Running org.jboss.test.ws.samples.secureejb.SecureEJBTestCase
    [junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 5.452 sec
    [junit] Test org.jboss.test.ws.samples.secureejb.SecureEJBTestCase FAILED


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 07:41:44 2006
From: jira-events at jboss.com (Ales Justin (JIRA))
Date: Fri, 1 Sep 2006 07:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-35) Allow retrieval
 of the collection instance from the bean
Message-ID: <8247706.1157110904615.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-35?page=all ]

Ales Justin closed JBMICROCONT-35.
----------------------------------

    Resolution: Done

Fixed Custom[Collection|List|Map|Set] so that default constructor doesn't set preinstantiated = true.
Added xml files for all preinstantiated tests.
Since preinstantiated lookup must pass through MetaDataVisitor.initialVisit(), instantiation method with KernelController was added.

> Allow retrieval of the collection instance from the bean
> --------------------------------------------------------
>
>                 Key: JBMICROCONT-35
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-35
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: MetaData
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>             Fix For:  JBossMC_2_0_0M1
>
>
> See org.jboss.test.kernel.config.test.CollectionTestCase#TODOtestCustomCollectionPreInstantiated
> Same issues apply to Lists, Sets, Maps, Arrays, etc.
> i.e. If the bean already has a collection value for the property that can be
> retrieved using the getter, we should be able to use that collection instance.
> Need to think about the configuration options and rules.
> Current rules are:
> 1) Use class specified in metadata
> 2) Use class specified on setter (if not an interface)
> 3) Use ArrayList

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 07:49:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 1 Sep 2006 07:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-472) Correct lines in
 RHS to match up with lines in rule source
Message-ID: <14103178.1157111383787.JavaMail.jira@cloud.prod.atl2.jboss.com>

Correct lines in RHS to match up with lines in rule source
----------------------------------------------------------

                 Key: JBRULES-472
                 URL: http://jira.jboss.com/jira/browse/JBRULES-472
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions: 3.0.4
            Reporter: Michael Neale
         Assigned To: Michael Neale
             Fix For: 3.1-m1


This means to calculate the correct line number, and make sure the RHS matches up with it for line number debugging.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 07:53:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 1 Sep 2006 07:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-472) Correct lines in
 RHS to match up with lines in rule source
In-Reply-To: <14103178.1157111383787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24543947.1157111623815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-472?page=all ]

Michael Neale resolved JBRULES-472.
-----------------------------------

    Resolution: Done

> Correct lines in RHS to match up with lines in rule source
> ----------------------------------------------------------
>
>                 Key: JBRULES-472
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-472
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.4
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 3.1-m1
>
>
> This means to calculate the correct line number, and make sure the RHS matches up with it for line number debugging.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 08:31:43 2006
From: jira-events at jboss.com (Christian Buggle (JIRA))
Date: Fri, 1 Sep 2006 08:31:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-45) ehcache-1.1.jar,
 bsh-2.0b1.jar declared in classpath are missing
Message-ID: <4262417.1157113903926.JavaMail.jira@cloud.prod.atl2.jboss.com>

ehcache-1.1.jar, bsh-2.0b1.jar declared in classpath are missing
----------------------------------------------------------------

                 Key: HIBERNATE-45
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-45
             Project: Hibernate
          Issue Type: Bug
         Environment: win32 Eclipse 3.2
            Reporter: Christian Buggle
         Assigned To: Steve Ebersole


There are 2 jars missing which are declared in the classpath of  Plugin 'org.hibernate.eclipse_3.2.0.beta6.jar' and 'org.hibernate.eclipse_3.2.0.beta7.jar'
namely: 
lib/hibernate/ehcache-1.1.jar
lib/tools/bsh-2.0b1.jar

No actual crashes or problems noticed yet. 


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 08:45:43 2006
From: jira-events at jboss.com (Christian Buggle (JIRA))
Date: Fri, 1 Sep 2006 08:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (HIBERNATE-45) ehcache-1.1.jar,
 bsh-2.0b1.jar declared in classpath are missing
In-Reply-To: <4262417.1157113903926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32414367.1157114743845.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/HIBERNATE-45?page=all ]

Christian Buggle closed HIBERNATE-45.
-------------------------------------

    Resolution: Done

jars are present in beta7

(sorry, mixed something up when double-checking, should haven been triple-checking)

> ehcache-1.1.jar, bsh-2.0b1.jar declared in classpath are missing
> ----------------------------------------------------------------
>
>                 Key: HIBERNATE-45
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-45
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: win32 Eclipse 3.2
>            Reporter: Christian Buggle
>         Assigned To: Steve Ebersole
>
> There are 2 jars missing which are declared in the classpath of  Plugin 'org.hibernate.eclipse_3.2.0.beta6.jar' and 'org.hibernate.eclipse_3.2.0.beta7.jar'
> namely: 
> lib/hibernate/ehcache-1.1.jar
> lib/tools/bsh-2.0b1.jar
> No actual crashes or problems noticed yet. 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 09:51:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 09:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <9302266.1157118703977.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342584 ] 
            
Brian Stansberry commented on JBAS-3345:
----------------------------------------

A big chunk of the tc5 folder is clustering related, and that's in "Don't care anymore" mode as well. Delete away!  :)

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 09:59:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 09:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-295) DistributedHashtable
 and ChannelFactory with XML config file
In-Reply-To: <32773016.1157106441257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30200109.1157119183986.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-295?page=all ]

Bela Ban updated JGRP-295:
--------------------------

    Fix Version/s: 2.4

> DistributedHashtable and ChannelFactory with XML config file
> ------------------------------------------------------------
>
>                 Key: JGRP-295
>                 URL: http://jira.jboss.com/jira/browse/JGRP-295
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Stefan Kassal
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> I think I have found an issue with DistributedHashtables (jgroups 2.4CR2)
> I have a XML file containing the protocol stack and create a ChannelFactory with that file.
> ChannelFactory  factory=new JChannelFactory(new File(configFilePathM));
> 	
> The DistributedHashtable is created with
> DistributedHashtable distHashM = new DistributedHashtable(distChannelNameM,factory,channelProps,true,TIMEOUT);
> 	
> The problem is that the constructor of the DistributedHashtable class which I want to use uses the following:
> channel=factory != null ? factory.createChannel(properties) : new JChannel(properties);
> 	
> That means it always tries to uses the properties to create the channel and you cannot force it to use the configuration of the factory.
> This could be solved in a way that you check if the properties is null and if it is you call  factory.createChannel()

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:01:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 10:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-293) Support for more
 system properties
In-Reply-To: <26071221.1157096358240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13229609.1157119303954.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-293?page=all ]

Bela Ban resolved JGRP-293.
---------------------------

    Resolution: Done

no action required on my side...

> Support for more system properties
> ----------------------------------
>
>                 Key: JGRP-293
>                 URL: http://jira.jboss.com/jira/browse/JGRP-293
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Optional
>             Fix For: 2.4
>
>
> ${jboss.mcast.ip.ttl:2}

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:01:47 2006
From: jira-events at jboss.com (Martin Isheim (JIRA))
Date: Fri, 1 Sep 2006 10:01:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-694) @OneToOne
 relation fails, when foreign key is in inverse side
Message-ID: <26748158.1157119307386.JavaMail.jira@cloud.prod.atl2.jboss.com>

@OneToOne relation fails, when foreign key is in inverse side
-------------------------------------------------------------

                 Key: EJBTHREE-694
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-694
             Project: EJB 3.0
          Issue Type: Bug
          Components: EJB3 Extensions
    Affects Versions: EJB 3.0 RC8 - FD
         Environment: JBoss AS 4.0.4 GA3 with jboss-EJB-3.0_RC8-FD installed as described in the release.
            Reporter: Martin Isheim


I defined a OneToOne relation from "UserEntity" to "PasswordEntity", with the foreign key in the "PasswordEntity" (for historical reasons).
With EntityManager.persist() the entities were inserted into the database, but the foreignKey column in "PasswordEntity" is empty.
Reading the "UserEntity" provides an empty relation.

Here the getter from "UserEntity":    

<code>
 private PasswordEntity password;

@OneToOne(optional = true, cascade = CascadeType.ALL)
    @PrimaryKeyJoinColumn(name = "ENTITYKEY", referencedColumnName = "USERKEY")
    public PasswordEntity getPassword() {
        return password;
    }
</code>

Since the relation is unidirectional, "PaswordEntity" has no getter/setter.
Regards.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:03:44 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Fri, 1 Sep 2006 10:03:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-115) NPE in ViewTopic
In-Reply-To: <1960202.1154560871633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3281417.1157119424163.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-115?page=all ]

Ryszard Kozmik reassigned JBFORUMS-115:
---------------------------------------

    Assignee: Ryszard Kozmik

> NPE in ViewTopic
> ----------------
>
>                 Key: JBFORUMS-115
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-115
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>
> Clicking this link http://forums.proto.jboss.com:8080/portal/index.html?ctrl:cmd=render&ctrl:window=default.default.DefaultCMSPortletWindow&t=12&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2Fviews%2Ftopics%2Fviewtopic_body.jsf , causes whole forums to dissapear and throw this exception:
> 18:06:20,855 ERROR [[/portal-forums]] Exception in FacesServlet
> java.lang.NullPointerException
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:393)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:94)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:128)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContainer.java:521)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.java:433)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInvocation.java:79)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.component.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.component.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.NavigationInterceptor.invoke(NavigationInterceptor.java:76)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.CacheInterceptor.invoke(CacheInterceptor.java:111)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ModesInterceptor.invoke(ModesInterceptor.java:88)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:87)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPostDispatchInterceptor.invoke(SessionPostDispatchInterceptor.java:65)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:129)
>         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.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:101)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
>         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>         at org.jboss.portal.server.app.impl.AbstractRequestContext.include(AbstractRequestContext.java:247)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:73)
>         at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:81)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:79)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPreDispatchInterceptor.invoke(SessionPreDispatchInterceptor.java:94)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.ValveInterceptor.invoke(ValveInterceptor.java:64)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:84)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:68)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:141)
>         at org.jboss.portal.core.command.RenderPageCommand.renderPortlets(RenderPageCommand.java:231)
>         at org.jboss.portal.core.command.RenderPageCommand.execute(RenderPageCommand.java:164)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:58)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:93)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:151)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:77)
>         at org.jboss.portal.core.CoreController.handle(CoreController.java:190)
>         at sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
>         at $Proxy136.handle(Unknown Source)
>         at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:76)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.server.SubjectAssociationInterceptor.invoke(SubjectAssociationInterceptor.java:47)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.PolicyAssociationInterceptor.invoke(PolicyAssociationInterceptor.java:52)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:69)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:184)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:87)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java:75)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:221)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:41:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 10:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-295) DistributedHashtable
 and ChannelFactory with XML config file
In-Reply-To: <32773016.1157106441257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4956152.1157121704679.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-295?page=all ]

Bela Ban resolved JGRP-295.
---------------------------

    Resolution: Done

done, fixed according to suggested solution. Also updated the javadoc

> DistributedHashtable and ChannelFactory with XML config file
> ------------------------------------------------------------
>
>                 Key: JGRP-295
>                 URL: http://jira.jboss.com/jira/browse/JGRP-295
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Stefan Kassal
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> I think I have found an issue with DistributedHashtables (jgroups 2.4CR2)
> I have a XML file containing the protocol stack and create a ChannelFactory with that file.
> ChannelFactory  factory=new JChannelFactory(new File(configFilePathM));
> 	
> The DistributedHashtable is created with
> DistributedHashtable distHashM = new DistributedHashtable(distChannelNameM,factory,channelProps,true,TIMEOUT);
> 	
> The problem is that the constructor of the DistributedHashtable class which I want to use uses the following:
> channel=factory != null ? factory.createChannel(properties) : new JChannel(properties);
> 	
> That means it always tries to uses the properties to create the channel and you cannot force it to use the configuration of the factory.
> This could be solved in a way that you check if the properties is null and if it is you call  factory.createChannel()

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:47:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 10:47:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.5.GA
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2580844.1157122063996.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis updated JBAS-3437:
-------------------------------------

     Summary: Get the 3.2-compatibility tests passing for 4.0.5.GA  (was: Get the 3.2-compatibility tests passing for 4.0.5.CR1)
    Assignee:     (was: Prabhat Jha)

> Get the 3.2-compatibility tests passing for 4.0.5.GA
> ----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             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
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:47:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 10:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.5.GA
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17094953.1157122064143.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis updated JBAS-3437:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)

> Get the 3.2-compatibility tests passing for 4.0.5.GA
> ----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             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
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:49:43 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 1 Sep 2006 10:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-744) unify and improve the
 messaging and scheduler implementation
Message-ID: <11413941.1157122183945.JavaMail.jira@cloud.prod.atl2.jboss.com>

unify and improve the messaging and scheduler implementation
------------------------------------------------------------

                 Key: JBPM-744
                 URL: http://jira.jboss.com/jira/browse/JBPM-744
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.2 alpha 1


* unify the scheduler and messaging implementation around the notion of a job
* add support for multiple concurrent threads competing for job execution.  synchronization is to be done by acquiring locks.  acquiring the locks is done with optimistic locking so that it also works for hsqldb


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:53:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 10:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-289) Optimize stacks.xml
In-Reply-To: <26182936.1156950223921.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4020918.1157122423830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-289?page=all ]

Bela Ban resolved JGRP-289.
---------------------------

    Resolution: Done

> Optimize stacks.xml
> -------------------
>
>                 Key: JGRP-289
>                 URL: http://jira.jboss.com/jira/browse/JGRP-289
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> We decided we want 4 configurations in stacks.xml:
>    1. fc-fast-minimalthreads
>    2. tcp (copy of the above, with TCP/TCPPING as transport)
>    3. fc-fast-minimalthreads-sync: alternative to #1, without FC and with message bundling disabled
>    4. tcp-sync: copy of #2, without FC and with message bundling disabled
>     * The default stacks (fc-fast and tcp) have FC and message bundling is enabled
>     * All stacks have FLUSH: because we use the Multiplexer, state transfer requires FLUSH
>     * VIEW_SYNC will be removed (because we use FLUSH, this is redundant)
>     * STREAMING_STATE_TRANSFER will be the default state transfer protocol
>           o STATE_TRANSFER is there, but commented
>           o According to Vladimir, these 2 protocols can be used interchangeably, the correct setState() and getState() methods will always be called
>     * For the TCP-based stack
>           o we use TCP_NIO as transport
>           o Discovery is TCPPING: we pass the list of hosts as a system property, default is localhost
>     * Vladimir and I will look at the resulting stacks.xml, and once it is correct, pass it on to Brian and Manik, so it can be tested with clustering and JBossCache

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 11:41:44 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 1 Sep 2006 11:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3596) JNDI static cache
Message-ID: <3008714.1157125304199.JavaMail.jira@cloud.prod.atl2.jboss.com>

JNDI static cache
-----------------

                 Key: JBAS-3596
                 URL: http://jira.jboss.com/jira/browse/JBAS-3596
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.CR1


Having a JNDI caching would improove performance on applications where JNDI is over used.



-- 
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

        


From jira-events at jboss.com  Fri Sep  1 11:51:43 2006
From: jira-events at jboss.com (Thiago Moreira (JIRA))
Date: Fri, 1 Sep 2006 11:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-27)
 CodeGen.getArrayWriteOp returns
 a invalid operation for a array of type short
Message-ID: <3166697.1157125903952.JavaMail.jira@cloud.prod.atl2.jboss.com>

CodeGen.getArrayWriteOp returns a invalid operation for a array of type short
-----------------------------------------------------------------------------

                 Key: JASSIST-27
                 URL: http://jira.jboss.com/jira/browse/JASSIST-27
             Project: Javassist
          Issue Type: Bug
            Reporter: Thiago Moreira
         Assigned To: Shigeru Chiba
            Priority: Critical



  The method CodeGen.getArrayWriteOp returns a invalid operation for a array of type short.

  The follow lines fix the bug:

   1655         case SHORT :
   1656             return SASTORE;

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 11:55:43 2006
From: jira-events at jboss.com (Thiago Moreira (JIRA))
Date: Fri, 1 Sep 2006 11:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-21) release javassist
 3.1 to ibiblio
Message-ID: <3529547.1157126143831.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JASSIST-21?page=comments#action_12342597 ] 
            
Thiago Moreira commented on JASSIST-21:
---------------------------------------


  The new versions of Javassist could be deployed in ibiblio/maven2 ?!?! 

> release javassist 3.1 to ibiblio
> --------------------------------
>
>                 Key: JASSIST-21
>                 URL: http://jira.jboss.com/jira/browse/JASSIST-21
>             Project: Javassist
>          Issue Type: Task
>         Environment: ibiblio.org/maven2
>            Reporter: Jesse Kuhnert
>
> I have a project using javassist 3.1 and would find it easier to manage if the ibiblio/maven2 repo hosted javassist 3.1 (already has 3.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

        


From jira-events at jboss.com  Fri Sep  1 12:07:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
Message-ID: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
-------------------------------------------------------------------------------

                 Key: JBAS-3597
                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMS service
         Environment: Java Version 1.4.2_09 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Client VM 
Java VM Version 1.4.2_09-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with

Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
	at java.lang.Thread.run(Thread.java:534)

For
MatrixTestContainer(jms_4_0_4_GA)
MatrixTestContainer(jms_4_0_x) 


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:09:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5888950.1157126983887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3597?page=all ]

Dimitris Andreadis updated JBAS-3597:
-------------------------------------

    Component/s: Test Suite

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:09:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3580) Error in
 org.jboss.test.jbossmq.test.UnackedUnitTestCase
In-Reply-To: <7836020.1156800287434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32808130.1157126984063.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3580?page=all ]

Dimitris Andreadis updated JBAS-3580:
-------------------------------------

    Comment: was deleted

> Error in org.jboss.test.jbossmq.test.UnackedUnitTestCase
> --------------------------------------------------------
>
>                 Key: JBAS-3580
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3580
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.CR1
>
>
> This seems like a clean-up problem of a previous test?
> testUnackedDurableTopic
> Error  - The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:93)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:572)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:171)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:643)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:177)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:185)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:15:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3598) Get the 4.0.5.GA
 testsuite-1.4 (JRockit) passing
Message-ID: <31303322.1157127343880.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

        


From jira-events at jboss.com  Fri Sep  1 12:19:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:19:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24789946.1157127584442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3494?page=all ]

Dimitris Andreadis updated JBAS-3494:
-------------------------------------

        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Test Suite
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:19:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:19:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13297509.1157127586069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3494?page=all ]

Dimitris Andreadis updated JBAS-3494:
-------------------------------------

    Issue Type: Task  (was: Bug)

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Test Suite
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:25:50 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:25:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3496) all tests under
 org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
In-Reply-To: <29133751.1155052872676.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26619327.1157127951019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3496?page=all ]

Dimitris Andreadis updated JBAS-3496:
-------------------------------------

           Issue Type: Task  (was: Bug)
        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)

> all tests under org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3496
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3496
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux -dev03 in qa, JRockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> This error does not happen with Sun JDK1.4.
> All test cases under org.jboss.test.cmp2.cmrtree.test have following error:
> Entity with primary key [.1.A.] already exists
> javax.ejb.DuplicateKeyException: Entity with primary key [.1.A.] already exists
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand.beforeInsert(JDBCInsertPKCreateCommand.java:99)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractCreateCommand.execute(JDBCAbstractCreateCommand.java:150)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:587)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:237)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:225)
> 	at org.jboss.ejb.EntityContainer.createLocalHome(EntityContainer.java:625)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
> 	at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
> 	at $Proxy204.create(ILjava.lang.String;Ljava.lang.String;)Lorg.jboss.test.cmp2.cmrtree.ejb.ALocal;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 12:37:45 2006
From: jira-events at jboss.com (Andrig Miller (JIRA))
Date: Fri, 1 Sep 2006 12:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-678) RemoteBinding
 annotation doesn't use the default client binding of the remoting
In-Reply-To: <8002416.1154618891359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27563733.1157128665750.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-678?page=all ]

Andrig Miller updated EJBTHREE-678:
-----------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD

Assign to fix version RC9, because we have a customer that needs this addressed for a current project.

> RemoteBinding annotation doesn't use the default client binding of the remoting
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-678
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. 
> When the jboss remoting service is not configured  using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. 
> The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value).
> I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration.
> The following fixes the issue using the first described approach:
> org.jboss.ejb3.stateless.ProxyDeployer
> public void initializeRemoteBindingMetadata()
>    {
>       remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class);
>       if (remoteBindings == null)
>   ...
>       }
>          else
>          {
>        	 // defaultClientBinding is more accurate that the constant in RemoteBinding 
>              if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) {
>                  binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory());
>              }
>             RemoteBinding[] list = {binding};
>             remoteBindings = new RemoteBindingsImpl(list);
>             advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings);
>          }
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:37:45 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3497) (21) test under
 org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException
 (jrockit)
In-Reply-To: <3943595.1155053113119.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4263597.1157128665925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3497?page=all ]

Dimitris Andreadis updated JBAS-3497:
-------------------------------------

              Summary: (21) test under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException (jrockit)  (was: All tests (21) under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException)
           Issue Type: Task  (was: Bug)
        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)
          Description: 
21 tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:

No such entity!
javax.ejb.ObjectNotFoundException: No such entity!
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
	at org.jboss.ejb.Container.invoke(Container.java:975)

  was:
All tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:

No such entity!
javax.ejb.ObjectNotFoundException: No such entity!
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
	at org.jboss.ejb.Container.invoke(Container.java:975)

Complete error log can be found at http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite-1.4/20060808052249/results/index.html.


> (21) test under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException (jrockit)
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3497
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3497
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux - dev03 in qa, java: Jrockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> 21 tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:
> No such entity!
> javax.ejb.ObjectNotFoundException: No such entity!
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
> 	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:39:44 2006
From: jira-events at jboss.com (Andrig Miller (JIRA))
Date: Fri, 1 Sep 2006 12:39:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-677) EJB3 deployments
 should be bound with rebind instead of bind
In-Reply-To: <7679261.1154618051633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15488968.1157128784535.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-677?page=all ]

Andrig Miller updated EJBTHREE-677:
-----------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD

Assign to fix version RC9, because we have a customer that needs this addressed for a current project.

> EJB3 deployments should be bound with rebind instead of bind
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-677
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-677
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Using bind instead of rebind may cause trouble when the JNDI implementation is persistent (e.g. in an ldap directory) because deploying a previously crashed application will fail. 
> I know that the current situation can also be seen as a feature because the developer cannot deploy two different beans with the same jndi name but this has in my opinion a lesser priority. Further the ejb 2.x stack uses rebind too.
> The request http://jira.jboss.com/jira/browse/EJBTHREE-51 describtes to use Util.rebind()  but in fisheye I saw Util.bind().

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:47:44 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Fri, 1 Sep 2006 12:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-630) Portal name
Message-ID: <19819056.1157129264242.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-630?page=comments#action_12342604 ] 
            
Ryszard Kozmik commented on JBPORTAL-630:
-----------------------------------------

Yeah, indeed it can be done like that. Nevertheless, I don't need this feature anymore. As you can see dependant task is resolved :-). Thanks

> Portal name
> -----------
>
>                 Key: JBPORTAL-630
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-630
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryszard Kozmik
>         Assigned To: Julien Viet
>             Fix For: 2.6 Final
>
>
> I need this: req.getPortalContext().getProperty("org.jboss.portal.property.name"));
> to be able to create root link in JBoss Forums.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:11:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 13:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3599) Implement
 MessageListener.block() in HAPartitionImpl
Message-ID: <21857984.1157130703800.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement MessageListener.block() in HAPartitionImpl
----------------------------------------------------

                 Key: JBAS-3599
                 URL: http://jira.jboss.com/jira/browse/JBAS-3599
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


Needed for proper use of JGroups FLUSH.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:23:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:23:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
Message-ID: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>

failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
--------------------------------------------------------------------------------

                 Key: JBAS-3600
                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Sacha Labourey
             Fix For: JBossAS-4.0.5.GA


test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?

Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
javax.management.loading.MLet,
javax.resource.ResourceException,
javax.resource.spi.ConnectionEvent,
javax.resource.spi.InvalidPropertyException,
javax.resource.spi.work.WorkEvent,
javax.security.jacc.EJBMethodPermission,
javax.security.jacc.EJBRoleRefPermission,
javax.security.jacc.WebResourcePermission,
javax.security.jacc.WebRoleRefPermission,
javax.security.jacc.WebUserDataPermission,
javax.xml.registry.JAXRException,
javax.xml.registry.RegistryException,
javax.xml.rpc.JAXRPCException,
javax.xml.rpc.ServiceException,
javax.xml.rpc.soap.SOAPFaultException,
javax.xml.soap.SOAPException
	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 13:23:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:23:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18487801.1157131424292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3600?page=all ]

Dimitris Andreadis reassigned JBAS-3600:
----------------------------------------

    Assignee:     (was: Sacha Labourey)

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 13:31:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:31:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3601) Switch copyright to
 RedHat Middleware LLC
Message-ID: <5022893.1157131903947.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch copyright to RedHat Middleware LLC
-----------------------------------------

                 Key: JBAS-3601
                 URL: http://jira.jboss.com/jira/browse/JBAS-3601
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


Something like:

/*
* JBoss, Home of Professional Open Source
* Copyright 2006, Red Hat Middleware LLC., and individual contributors as indicated 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:37:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:37:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-539) Rig an RI and
 investigate
 the behavior of an XASession in absence of a global transaction
In-Reply-To: <3913639.1157059277734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4577773.1157132264114.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-539?page=all ]

Ovidiu Feodorov closed JBMESSAGING-539.
---------------------------------------

    Resolution: Won't Fix

Not necessary anymore. JBossMQ does it that way, and Sonic does it the same way, that's good enough.

> Rig an RI and investigate the behavior of an XASession in absence of a global transaction
> -----------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-539
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-539
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Install the Sun's RI and run a simple test case with an XASession sending a message in an absence of a global transaction.
> The test case should determine whether the message is sent to the destination or not when producer.send() completes.
> Add the same test case to Messaging's testsuite.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:43:44 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Fri, 1 Sep 2006 13:43:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-257) Test extender test
 in a scoped environment
Message-ID: <18378733.1157132624056.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-257?page=comments#action_12342611 ] 
            
Kabir Khan commented on JBAOP-257:
----------------------------------

Got the mains stuff working locally testing methods.

Also need to test fields, constructors.

Once I have got the base loaded no parent delegation test passing completely, need to make sure that the correct (i.e. child) copy of per instance, per class, per joinpoint etc. scoped interceptors get called

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:45:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3492) Test Failure with
 JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
In-Reply-To: <31141571.1155047232621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18574087.1157132744759.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3492?page=all ]

Dimitris Andreadis updated JBAS-3492:
-------------------------------------

           Issue Type: Task  (was: Bug)
          Component/s: CMP service
        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)
          Description: 
Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error

Error, bean instance was discarded!
javax.ejb.FinderException: Error, bean instance was discarded!
	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer

On the server log, I see following for the first error in test suite.

2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
onTesterLocal.runtimeExceptionNoTx():
java.lang.RuntimeException: Runtime exception without a transaction
        at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
        at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
        at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
        at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
        at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
        at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
        at org.jboss.ejb.Container.invoke(Container.java:954)

  was:
Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error which can also be found at http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite-1.4/20060807035911/results/index.html.

Error, bean instance was discarded!
javax.ejb.FinderException: Error, bean instance was discarded!
	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer

On the server log, I see following for the first error in test suite.

2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
onTesterLocal.runtimeExceptionNoTx():
java.lang.RuntimeException: Runtime exception without a transaction
        at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
        at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
        at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
        at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
        at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
        at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
        at org.jboss.ejb.Container.invoke(Container.java:954)





             Assignee: Alexey Loubyansky

> Test Failure with JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3492
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3492
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, CMP service
>         Environment: linux - dev03 in qa lab, JRockit - java version "1.4.2_11"
>            Reporter: Prabhat Jha
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error
> Error, bean instance was discarded!
> javax.ejb.FinderException: Error, bean instance was discarded!
> 	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer
> On the server log, I see following for the first error in test suite.
> 2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
> 2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
> 2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
> onTesterLocal.runtimeExceptionNoTx():
> java.lang.RuntimeException: Runtime exception without a transaction
>         at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
>         at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
>         at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
>         at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
>         at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
>         at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
>         at org.jboss.ejb.Container.invoke(Container.java:954)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:49:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3602) 3 failing tests
 org.jboss.test.jacc.test (jrockit)
Message-ID: <18072439.1157132983856.JavaMail.jira@cloud.prod.atl2.jboss.com>

3 failing tests org.jboss.test.jacc.test (jrockit)
--------------------------------------------------

                 Key: JBAS-3602
                 URL: http://jira.jboss.com/jira/browse/JBAS-3602
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


org.jboss.test.jacc.test

EJBSpecUnitTestCase(JACC)
EJBSpecUnitTestCase(JACC+SecurityMgr) 

testStressNoJaasCache Failure Thread error count == 0
junit.framework.AssertionFailedError: Thread error count == 0
	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStress(EJBSpecUnitTestCase.java:822)
	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStressNoJaasCache(EJBSpecUnitTestCase.java:842)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

testGetCallerPrincipal Failure Was able to call StatelessSession.echo
junit.framework.AssertionFailedError: Was able to call StatelessSession.echo
	at org.jboss.test.security.test.EJBSpecUnitTestCase.testGetCallerPrincipal(EJBSpecUnitTestCase.java:194)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:51:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:51:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-410) java:/JmsXA
 in no-tx context does not work the same way as JBossMQ
Message-ID: <23024230.1157133104225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-410:
-------------------------------------------

    Assignee: Ovidiu Feodorov  (was: Clebert Suconic)

> java:/JmsXA in no-tx context does not work the same way as JBossMQ
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-410
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR2
>            Reporter: Elias Ross
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory.
> Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility.
> The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced.
>       QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA");
> ...
>       QueueConnection queueConnection = queueCF.createQueueConnection();
>       QueueSession queueSession =
>           queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
>       QueueSender queueSender = queueSession.createSender(queue);
>       ObjectMessage om = queueSession.createObjectMessage();
>       queueSender.send(om);
>       queueSender.close();
>       queueSession.close();
>       queueConnection.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

        


From jira-events at jboss.com  Fri Sep  1 13:55:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3580) Error in
 org.jboss.test.jbossmq.test.UnackedUnitTestCase
In-Reply-To: <7836020.1156800287434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <419107.1157133343870.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3580?page=all ]

Dimitris Andreadis updated JBAS-3580:
-------------------------------------

      Environment: 
Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


  was:
Java Version 1.4.2_09 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Client VM 
Java VM Version 1.4.2_09-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)
      Description: 
testDummyLast - Error
No durable subscription found for subscription: test
javax.jms.InvalidDestinationException: No durable subscription found for subscription: test
	at org.jboss.mq.sm.AbstractStateManager.getDurableTopic(AbstractStateManager.java:164)
	at org.jboss.mq.server.JMSDestinationManager.getDurableTopic(JMSDestinationManager.java:777)
	at org.jboss.mq.server.JMSServerInterceptorSupport.getDurableTopic(JMSServerInterceptorSupport.java:181)
	at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:207)
	at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:548)
	at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:162)
	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:214)
	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
	at java.lang.Thread.run(Unknown Source)

 

  was:
This seems like a clean-up problem of a previous test?

testUnackedDurableTopic
Error  - The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:93)
	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:572)
	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:171)
	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:643)
	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:177)
	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:185)
	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
	at java.lang.Thread.run(Thread.java:534)




> Error in org.jboss.test.jbossmq.test.UnackedUnitTestCase
> --------------------------------------------------------
>
>                 Key: JBAS-3580
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3580
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> testDummyLast - Error
> No durable subscription found for subscription: test
> javax.jms.InvalidDestinationException: No durable subscription found for subscription: test
> 	at org.jboss.mq.sm.AbstractStateManager.getDurableTopic(AbstractStateManager.java:164)
> 	at org.jboss.mq.server.JMSDestinationManager.getDurableTopic(JMSDestinationManager.java:777)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.getDurableTopic(JMSServerInterceptorSupport.java:181)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:207)
> 	at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:548)
> 	at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:162)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:214)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 13:59:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-536) The
 CallbackServer cannot
 be contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30777263.1157133584119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Ovidiu Feodorov updated JBMESSAGING-536:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10316556.1157133584299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=all ]

Ovidiu Feodorov updated JBMESSAGING-528:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20584258.1157133584557.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=all ]

Ovidiu Feodorov updated JBMESSAGING-499:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:45 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14089135.1157133585200.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov updated JBMESSAGING-525:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:45 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <20586228.1157133585411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov updated JBMESSAGING-432:
----------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:45 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-526) JMSRedelivered
 flag not correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19584363.1157133585588.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Ovidiu Feodorov updated JBMESSAGING-526:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:07:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 14:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21037655.1157134063909.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3600?page=comments#action_12342613 ] 
            
Brian Stansberry commented on JBAS-3600:
----------------------------------------

The serialVersionUID probably is computed differently.  From the java.io.Serializable javadoc:

"However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, ...."

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:11:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
Message-ID: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>

6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
-----------------------------------------------------------------------------------

                 Key: JBAS-3603
                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JCA service, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Weston Price
             Fix For: JBossAS-4.0.5.GA


All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with

Transaction already active, cannot nest transactions.
javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
	at org.jboss.tm.TxManager.begin(TxManager.java:209)
	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)

OR

Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
	... 16 more


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:15:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6741376.1157134543842.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3600?page=comments#action_12342614 ] 
            
Dimitris Andreadis commented on JBAS-3600:
------------------------------------------

Cool. I had thought the algorigthm was standard more or less. I guess we need to exclude those classes from the test OR store a different set of GUIDs per tested JVM.

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:21:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3605) test failures
 org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase
 (jrockit)
Message-ID: <9882655.1157134903814.JavaMail.jira@cloud.prod.atl2.jboss.com>

test failures org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase (jrockit)
---------------------------------------------------------------------------------------------------

                 Key: JBAS-3605
                 URL: http://jira.jboss.com/jira/browse/JBAS-3605
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testGetCustom Failure expected:<InitialValue> but was:<changed>
junit.framework.ComparisonFailure: expected:<InitialValue> but was:<changed>
	at org.jboss.test.jmx.test.JMXInvokerUnitTestCase.testGetCustom(JMXInvokerUnitTestCase.java:85)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:35:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:35:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3606) failed
 org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
Message-ID: <4834417.1157135743871.JavaMail.jira@cloud.prod.atl2.jboss.com>

failed org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
----------------------------------------------------------------

                 Key: JBAS-3606
                 URL: http://jira.jboss.com/jira/browse/JBAS-3606
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


testSecureHttpInvokerFailure Failure
Should not have been able to lookup(jmx)
junit.framework.AssertionFailedError: Should not have been able to lookup(jmx)
	at org.jboss.test.naming.test.SecurityUnitTestCase.testSecureHttpInvokerFailure(SecurityUnitTestCase.java:77)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:37:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3607) failing
 org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
Message-ID: <24350644.1157135863866.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
-------------------------------------------------------------------

                 Key: JBAS-3607
                 URL: http://jira.jboss.com/jira/browse/JBAS-3607
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: EJB2, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA


testEjbRemoveNotCalledForEveryCall Failure
createCounter expected:<1> but was:<0>
junit.framework.AssertionFailedError: createCounter expected:<1> but was:<0>
	at org.jboss.test.session.test.EjbRemoveUnitTestCase.testEjbRemoveNotCalledForEveryCall(EjbRemoveUnitTestCase.java:96)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:39:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3608) 2 failing tests
 org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
Message-ID: <3989808.1157135983973.JavaMail.jira@cloud.prod.atl2.jboss.com>

2 failing tests org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
-------------------------------------------------------------------------

                 Key: JBAS-3608
                 URL: http://jira.jboss.com/jira/browse/JBAS-3608
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite, Web Services
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


testHandlerFlowServerReturn Failure
testHandlerFlowAllPass Failure

Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
junit.framework.AssertionFailedError: Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.assertHandlerProtocol(HandlerFlowTestCase.java:140)
	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.testHandlerFlowServerReturn(HandlerFlowTestCase.java:134)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:39:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:39:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3609) failing
 org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
Message-ID: <23815383.1157135984122.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
-----------------------------------------------------------------

                 Key: JBAS-3609
                 URL: http://jira.jboss.com/jira/browse/JBAS-3609
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite, Web Services
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


testGetVersion Failure
expected:<Version-1.0> but was:<null>
junit.framework.ComparisonFailure: expected:<Version-1.0> but was:<null>
	at org.jboss.test.webservice.jbws70.JBWS70TestCase.testGetVersion(JBWS70TestCase.java:74)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:17:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3604) 2 failed tests -
 org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
Message-ID: <19803940.1157134663902.JavaMail.jira@cloud.prod.atl2.jboss.com>

2 failed tests - org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
---------------------------------------------------------------------------

                 Key: JBAS-3604
                 URL: http://jira.jboss.com/jira/browse/JBAS-3604
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testPersistentJndiXMBean Error Hello not bound
javax.naming.NameNotFoundException: Hello not bound
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
	at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
	at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
	at org.jboss.naming.NamingService.invoke(NamingService.java:354)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.test.jmx.interceptors.JNDIPersistence.invoke(JNDIPersistence.java:114)
	at org.jboss.test.jmx.interceptors.JNDISecurity.invoke(JNDISecurity.java:130)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
	at $Proxy1.lookup(Ljavax.naming.Name;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testPersistentJndiXMBean(DeployXMBeanUnitTestCase.java:520)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)

 testSecuredJndiXMBean Failure Was able to invoke secretEcho
junit.framework.AssertionFailedError: Was able to invoke secretEcho
	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testSecuredJndiXMBean(DeployXMBeanUnitTestCase.java:459)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:53:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3610) failing
 org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl)
 (jrockit)
Message-ID: <768700.1157136823860.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl) (jrockit)
-------------------------------------------------------------------------------------------------

                 Key: JBAS-3610
                 URL: http://jira.jboss.com/jira/browse/JBAS-3610
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite, Web Services
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


testWithTransportOptions Error

Call invocation failed: Could not transmit message; nested exception is: javax.xml.soap.SOAPException: Could not transmit message
java.rmi.RemoteException: Call invocation failed: Could not transmit message; nested exception is: 
	javax.xml.soap.SOAPException: Could not transmit message
	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:718)
	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: javax.xml.soap.SOAPException: Could not transmit message
	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:204)
	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
	... 23 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
	at org.jboss.remoting.Client.invoke(Client.java:525)
	at org.jboss.remoting.Client.invoke(Client.java:488)
	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(BLjava.lang.Throwable;Ljava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(BLjava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush()V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_bc;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.j()V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_ba;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(BI)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j()V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake()V(DashoA12275:???)
	at sun.net.www.protocol.https.HttpsClient.afterConnect()V(DashoA12275:???)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect()V(DashoA12275:???)
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:569)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream()Ljava.io.OutputStream;(DashoA12275:???)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:163)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
	at org.jboss.remoting.Client.invoke(Client.java:525)
	at org.jboss.remoting.Client.invoke(Client.java:488)
	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:59:44 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 1 Sep 2006 14:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
In-Reply-To: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6449272.1157137184093.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3603?page=comments#action_12342615 ] 
            
Weston Price commented on JBAS-3603:
------------------------------------

I am assuing JRockit 1.4. This works fine for me on Windows. What platform are you testing on? 



> 6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-3603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with
> Transaction already active, cannot nest transactions.
> javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
> 	at org.jboss.tm.TxManager.begin(TxManager.java:209)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)
> OR
> Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
> 	... 16 more

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:01:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3611) Get the
 jboss-4.0-testsuite-sun-1.5 passing
Message-ID: <20914255.1157137303968.JavaMail.jira@cloud.prod.atl2.jboss.com>

Get the jboss-4.0-testsuite-sun-1.5 passing
-------------------------------------------

                 Key: JBAS-3611
                 URL: http://jira.jboss.com/jira/browse/JBAS-3611
             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 for sun jdk1.5 test run failures

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:01:44 2006
From: jira-events at jboss.com (G?bor Lipt?k (JIRA))
Date: Fri, 1 Sep 2006 15:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-444) patch to support
 Notes attribute on decision table Package
In-Reply-To: <9769524.1156268351914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8446581.1157137304276.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-444?page=comments#action_12342616 ] 
            
G?bor Lipt?k commented on JBRULES-444:
--------------------------------------

This would make the Notes field (at the package level top of the spreadsheet), injected as a comment at the package level of the generated rules. You could run the patched code against several of the example spreadsheets provided to see it in action.

> patch to support Notes attribute on decision table Package
> ----------------------------------------------------------
>
>                 Key: JBRULES-444
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-444
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Mark Proctor
>            Priority: Optional
>             Fix For: 3.0.4
>
>         Attachments: jboss_rules_decisiontable_package_notes.diff
>
>
> patch attached

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:03:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3612) failing
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
Message-ID: <23206066.1157137423945.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
----------------------------------------------------------------------

                 Key: JBAS-3612
                 URL: http://jira.jboss.com/jira/browse/JBAS-3612
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


test402Compatibility Failure
Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
org.jboss.console.manager.PluginManager$1,
org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
org.jboss.console.plugins.helpers.BasePluginWrapper,
org.jboss.console.plugins.helpers.servlet.TabTag,
org.jboss.console.remote.InvokerServlet,
org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
org.jboss.invocation.jrmp.server.JRMPInvoker,
org.jboss.proxy.ClientContainerEx,
org.jboss.proxy.ejb.DynamicIIOPStub,
org.jboss.proxy.ejb.HomeHandleImplIIOP,
org.jboss.tm.iiop._CoordinatorExtStub,
org.jboss.tm.iiop._TransactionFactoryExtStub,
org.jboss.tm.iiop._TransactionServiceStub
	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

 test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
org.jboss.aspects.versioned.StateManager,
org.jboss.console.manager.PluginManager$1,
org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
org.jboss.console.plugins.helpers.BasePluginWrapper,
org.jboss.console.plugins.helpers.servlet.TabTag,
org.jboss.console.remote.InvokerServlet,
org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
org.jboss.invocation.jrmp.server.JRMPInvoker,
org.jboss.monitor.alarm.AlarmNotification,
org.jboss.monitor.alarm.AlarmTableNotification,
org.jboss.proxy.ejb.DynamicIIOPStub,
org.jboss.proxy.ejb.HomeHandleImplIIOP,
org.jboss.tm.iiop._CoordinatorExtStub,
org.jboss.tm.iiop._TransactionFactoryExtStub,
org.jboss.tm.iiop._TransactionServiceStub

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:03:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:03:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3612) failing
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <23206066.1157137423945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <481967.1157137424093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3612?page=all ]

Dimitris Andreadis updated JBAS-3612:
-------------------------------------

    Environment: 
Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


> failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> ----------------------------------------------------------------------
>
>                 Key: JBAS-3612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3612
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility Failure
> Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.proxy.ClientContainerEx,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
> org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.monitor.alarm.AlarmNotification,
> org.jboss.monitor.alarm.AlarmTableNotification,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:05:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:05:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3613) failing test in
 org.jboss.test.iiop.test.ParameterPassingStressTestCase
Message-ID: <18562400.1157137544244.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase
-----------------------------------------------------------------------

                 Key: JBAS-3613
                 URL: http://jira.jboss.com/jira/browse/JBAS-3613
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: IIOP service, Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Francisco Reverbel
             Fix For: JBossAS-4.0.5.GA


test_getException Error

Invalid indirection to offset 1704
java.io.IOException: Invalid indirection to offset 1704
	at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.read_Array(ValueHandlerImpl.java:756)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:325)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:1989)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2213)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2310)
	at org.jacorb.orb.Any.read_value(Any.java:816)
	at org.jacorb.orb.CDRInputStream.read_any(CDRInputStream.java:673)
	at com.sun.corba.se.impl.javax.rmi.CORBA.Util.readAny(Util.java:401)
	at javax.rmi.CORBA.Util.readAny(Util.java:92)
	at org.jboss.iiop.rmi.marshal.CDRStream$ObjectReader.read(CDRStream.java:618)
	at org.jboss.iiop.rmi.marshal.strategy.StubStrategy.readRetval(StubStrategy.java:226)
	at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:128)
	at org.jboss.test.iiop.interfaces._StatelessSession_Stub.getException(Unknown Source)
	at org.jboss.test.iiop.test.ParameterPassingStressTestCase.test_getException(ParameterPassingStressTestCase.java:355)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:05:45 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3614) failing
 org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
Message-ID: <5797013.1157137545169.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
-----------------------------------------------------------------------

                 Key: JBAS-3614
                 URL: http://jira.jboss.com/jira/browse/JBAS-3614
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA


testRMMResourceImplementsMBean Failure

testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
junit.framework.AssertionFailedError: testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
	at org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase.testRMMResourceImplementsMBean(ModelMBeanTestCase.java:150)
 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:07:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3615) failing test in
 org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
Message-ID: <10850104.1157137663981.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing test in org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
------------------------------------------------------------------------------

                 Key: JBAS-3615
                 URL: http://jira.jboss.com/jira/browse/JBAS-3615
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testMalformed Failure

invalid object name: domain:=,foo=bar
junit.framework.AssertionFailedError: invalid object name: domain:=,foo=bar
	at org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase$FullNameTEST.testMalformed(MalformedTestCase.java:152)
 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:09:44 2006
From: jira-events at jboss.com (G?bor Lipt?k (JIRA))
Date: Fri, 1 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-447) correct
 NullPointer when processing PRIORITY rule tag
In-Reply-To: <21683851.1156360189213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6496865.1157137784034.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-447?page=all ]

G?bor Lipt?k updated JBRULES-447:
---------------------------------

    Attachment: PriorityTest.xls

NullPointer with PRIORITY column

> correct NullPointer when processing PRIORITY rule tag
> -----------------------------------------------------
>
>                 Key: JBRULES-447
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-447
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Michael Neale
>         Attachments: jboss_rules_priority.diff, PriorityTest.xls
>
>
> diff attached. I'm not sure if using LshBuilder is the correct thing to do ...

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:09:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3616) failing test
 org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
Message-ID: <29398985.1157137784152.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing test org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
-----------------------------------------------------------

                 Key: JBAS-3616
                 URL: http://jira.jboss.com/jira/browse/JBAS-3616
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testMBeanInfoMarshalling Failure

Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
	at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:09:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 1 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1014)
 NavigationPortlet enhancements
In-Reply-To: <28936719.1157040861641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21297348.1157137784328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1014?page=all ]

Roy Russo resolved JBPORTAL-1014.
---------------------------------

    Fix Version/s: 2.6.Alpha1
       Resolution: Done

moving submenu to its own task, as it depends on the new theme.

> NavigationPortlet enhancements
> ------------------------------
>
>                 Key: JBPORTAL-1014
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1014
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> 1. Add explicit ordering support
> 2. Add localization support
> 3. Investigate feasibility of adding submenu support for subpage listing.
> All configuration options should be made available in the portlet.xml and overriden as preferences in the instances.xml.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:11:43 2006
From: jira-events at jboss.com (G?bor Lipt?k (JIRA))
Date: Fri, 1 Sep 2006 15:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-447) correct
 NullPointer when processing PRIORITY rule tag
In-Reply-To: <21683851.1156360189213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12308222.1157137903927.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-447?page=comments#action_12342620 ] 
            
G?bor Lipt?k commented on JBRULES-447:
--------------------------------------

Attached an example XLS. Incidentally you could also use this as an example for

http://jira.jboss.com/jira/browse/JBRULES-444

Thanks

> correct NullPointer when processing PRIORITY rule tag
> -----------------------------------------------------
>
>                 Key: JBRULES-447
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-447
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Michael Neale
>         Attachments: jboss_rules_priority.diff, PriorityTest.xls
>
>
> diff attached. I'm not sure if using LshBuilder is the correct thing to do ...

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:11:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:11:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3617) 3 failing tests in
 org.jboss.test.util.test.PropertyEditorsUnitTestCase
Message-ID: <15495472.1157137904044.JavaMail.jira@cloud.prod.atl2.jboss.com>

3 failing tests in org.jboss.test.util.test.PropertyEditorsUnitTestCase
-----------------------------------------------------------------------

                 Key: JBAS-3617
                 URL: http://jira.jboss.com/jira/browse/JBAS-3617
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testEditorSearchPath Failure
Found org.jboss.util.propertyeditor in search path
junit.framework.AssertionFailedError: Found org.jboss.util.propertyeditor in search path
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testEditorSearchPath(PropertyEditorsUnitTestCase.java:127)


testJavaLangEditors Failure
Found property editor for: class java.lang.Boolean
junit.framework.AssertionFailedError: Found property editor for: class java.lang.Boolean
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJavaLangEditors(PropertyEditorsUnitTestCase.java:188)

testJBossEditors Failure
Found property editor for: class javax.management.ObjectName
junit.framework.AssertionFailedError: Found property editor for: class javax.management.ObjectName
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJBossEditors(PropertyEditorsUnitTestCase.java:306)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:15:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:15:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
In-Reply-To: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7576079.1157138144133.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3603?page=all ]

Dimitris Andreadis updated JBAS-3603:
-------------------------------------

    Environment: 
Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


> 6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-3603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with
> Transaction already active, cannot nest transactions.
> javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
> 	at org.jboss.tm.TxManager.begin(TxManager.java:209)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)
> OR
> Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
> 	... 16 more

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:15:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 1 Sep 2006 15:15:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1017) Submenu support
 in NavigationPortlet
Message-ID: <8700605.1157138144292.JavaMail.jira@cloud.prod.atl2.jboss.com>

Submenu support in NavigationPortlet
------------------------------------

                 Key: JBPORTAL-1017
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1017
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo




-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:15:44 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Fri, 1 Sep 2006 15:15:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-678) RemoteBinding
 annotation doesn't use the default client binding of the remoting
In-Reply-To: <8002416.1154618891359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20987352.1157138144655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-678?page=comments#action_12342621 ] 
            
Bill Burke commented on EJBTHREE-678:
-------------------------------------

Make @RemoteBinding.clientBindUrl default to "" and we'll check for that.

> RemoteBinding annotation doesn't use the default client binding of the remoting
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-678
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. 
> When the jboss remoting service is not configured  using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. 
> The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value).
> I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration.
> The following fixes the issue using the first described approach:
> org.jboss.ejb3.stateless.ProxyDeployer
> public void initializeRemoteBindingMetadata()
>    {
>       remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class);
>       if (remoteBindings == null)
>   ...
>       }
>          else
>          {
>        	 // defaultClientBinding is more accurate that the constant in RemoteBinding 
>              if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) {
>                  binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory());
>              }
>             RemoteBinding[] list = {binding};
>             remoteBindings = new RemoteBindingsImpl(list);
>             advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings);
>          }
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 16:01:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 16:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1900) Clustered webapp
 shouldn't require ClusteredSingleSignOn
Message-ID: <14638054.1157140904035.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1900?page=all ]

Brian Stansberry updated JBAS-1900:
-----------------------------------

                   Summary: Clustered webapp shouldn't require ClusteredSingleSignOn  (was: Clustered webapp shouldn't require ClusteredSingleSignon?)
    Workaround Description: I haven't tested this, so buyer beware. The request notes that using ClusteredSSO is not an option due to different sets of users for different webapps. Set the "requireReauthentication" attribute in the ClusteredSingleSignOnValve to "true".  Each request will then be reauthenticated by the security layer, which should prevent users from one set accessing resources meant for another set.
                Workaround: [Workaround Exists]

Suggested workaround added.

> Clustered webapp shouldn't require ClusteredSingleSignOn
> --------------------------------------------------------
>
>                 Key: JBAS-1900
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1900
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Security
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Stan Silvert
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> A customer had three webapps.  The set of users for each webapp is different.  So, they don't want single signon behavior.  They do want HttpSessionReplication to take care of the credentials so that the user doesn't need to sign on when redirected to another server.  It was found that we needed to enable clustered single signon to get this to work.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 16:13:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 1 Sep 2006 16:13:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-695) support
 properties service in ejb3
Message-ID: <18560791.1157141623768.JavaMail.jira@cloud.prod.atl2.jboss.com>

support properties service in ejb3
----------------------------------

                 Key: EJBTHREE-695
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-695
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: William DeCoste
         Assigned To: William DeCoste
             Fix For: EJB 3.0 RC9 - 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

        


From jira-events at jboss.com  Fri Sep  1 17:07:43 2006
From: jira-events at jboss.com (Alex Pinkin (JIRA))
Date: Fri, 1 Sep 2006 17:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3618) repository-zip
 target in
 build-release.xml doesn't consistently overwrite default config with all
Message-ID: <18718633.1157144863997.JavaMail.jira@cloud.prod.atl2.jboss.com>

repository-zip target in build-release.xml doesn't consistently overwrite default config with all
-------------------------------------------------------------------------------------------------

                 Key: JBAS-3618
                 URL: http://jira.jboss.com/jira/browse/JBAS-3618
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Alex Pinkin


   <target name="repository-zip"
     description="Create a canonical binaries for the repository">
     <mkdir dir="${version}/repository" />
     <echo message="jboss.dist=${jboss.dist}" />
     <!-- Create a unified server/lib directory -->
     <copy todir="${jboss.dist}/server/lib">
       <fileset dir="${jboss.dist}/server/minimal/lib" />
       <fileset dir="${jboss.dist}/server/default/lib" />
       <fileset dir="${jboss.dist}/server/all/lib" />
       <!-- Include the prematurely added quartz stuff for ejb3 config -->
       <fileset dir="${jboss.thirdparty}/quartz/lib" />
     </copy>
     <!-- Create a unified server/deploy directory -->
     <copy todir="${jboss.dist}/server/deploy">
       <fileset dir="${jboss.dist}/server/default/deploy" />
       <fileset dir="${jboss.dist}/server/all/deploy">
         <exclude name="jms/**" />
       </fileset>
       <!-- Include the prematurely added quartz stuff for ejb3 config -->
       <fileset dir="${jboss.cvs.dir}/connector/output/lib">
         <include name="quartz-ra.rar" />
       </fileset>
     </copy>
     <copy todir="${jboss.dist}/server/deploy-ha">
       <fileset dir="${jboss.dist}/server/all">
         <include name="deploy/jms/**" />
         <include name="deploy-hasingleton/**" />
         <include name="farm/**" />
       </fileset>
     </copy>

Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps.

There is overwrite=true attribute which need to be added to force overwrites.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 17:09:44 2006
From: jira-events at jboss.com (Alex Pinkin (JIRA))
Date: Fri, 1 Sep 2006 17:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3618) repository-zip
 target in
 build-release.xml doesn't consistently overwrite default config with all
In-Reply-To: <18718633.1157144863997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12075845.1157144984014.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3618?page=all ]

Alex Pinkin updated JBAS-3618:
------------------------------

          Component/s: Build System
        Fix Version/s: JBossAS-4.0.5.GA
    Affects Version/s: JBossAS-4.0.4.GA

> repository-zip target in build-release.xml doesn't consistently overwrite default config with all
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3618
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3618
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Alex Pinkin
>             Fix For: JBossAS-4.0.5.GA
>
>
>    <target name="repository-zip"
>      description="Create a canonical binaries for the repository">
>      <mkdir dir="${version}/repository" />
>      <echo message="jboss.dist=${jboss.dist}" />
>      <!-- Create a unified server/lib directory -->
>      <copy todir="${jboss.dist}/server/lib">
>        <fileset dir="${jboss.dist}/server/minimal/lib" />
>        <fileset dir="${jboss.dist}/server/default/lib" />
>        <fileset dir="${jboss.dist}/server/all/lib" />
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.thirdparty}/quartz/lib" />
>      </copy>
>      <!-- Create a unified server/deploy directory -->
>      <copy todir="${jboss.dist}/server/deploy">
>        <fileset dir="${jboss.dist}/server/default/deploy" />
>        <fileset dir="${jboss.dist}/server/all/deploy">
>          <exclude name="jms/**" />
>        </fileset>
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.cvs.dir}/connector/output/lib">
>          <include name="quartz-ra.rar" />
>        </fileset>
>      </copy>
>      <copy todir="${jboss.dist}/server/deploy-ha">
>        <fileset dir="${jboss.dist}/server/all">
>          <include name="deploy/jms/**" />
>          <include name="deploy-hasingleton/**" />
>          <include name="farm/**" />
>        </fileset>
>      </copy>
> Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps.
> There is overwrite=true attribute which need to be added to force overwrites.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 18:27:44 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Fri, 1 Sep 2006 18:27:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <4964465.1157149664076.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment: new_splash_left_aligned.jpg

Hey James.. the new splash screen is looking great.. I got around to integrating it along with your updated progress bar/message placement and I had a few comments/suggestions:

1) The BMP you sent didn't have any shadowing effects around the border, so it kind of "disappears" into the background if you're looking at something that is white (for example a web page in a browser or similar). Would you mind re-creating the splash with some kind of fade-out or border affect similar to what you showed in your original proposal?

2) Apparently the "loading" message text in eclipse is left-aligned only, meaning it doesn't flush over to the right side of the progress bar like in the mockup you sent. Do you think it would ruin the flow of the new splash screen if we changed the JBoss logo over to the right side, and put the progress message on the left? I'm attaching a screenshot of what the current splash looks like w/ the left aligned text.

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:05:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 1 Sep 2006 20:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5465193.1157155543852.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=comments#action_12342657 ] 
            
Tim Fox commented on JBMESSAGING-505:
-------------------------------------

The current solution to this makes a copy of the entire receivers list for every message that is sent through the router.

This is likely to have an adverse effect on performance, especially when there are many receivers.

A better solution should be found to the race condition that does not involve cloning the list.

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:05:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 1 Sep 2006 20:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25719159.1157155543965.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Tim Fox reopened JBMESSAGING-505:
---------------------------------

             

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:07:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 1 Sep 2006 20:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1971670.1157155663868.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Tim Fox updated JBMESSAGING-505:
--------------------------------

    Fix Version/s: 1.0.1.GA
                       (was: 1.0.1.CR5)

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:41:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 1 Sep 2006 20:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-678) RemoteBinding
 annotation doesn't use the default client binding of the remoting
In-Reply-To: <8002416.1154618891359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26123642.1157157704259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-678?page=all ]

William DeCoste closed EJBTHREE-678.
------------------------------------

    Resolution: Done

> RemoteBinding annotation doesn't use the default client binding of the remoting
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-678
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. 
> When the jboss remoting service is not configured  using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. 
> The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value).
> I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration.
> The following fixes the issue using the first described approach:
> org.jboss.ejb3.stateless.ProxyDeployer
> public void initializeRemoteBindingMetadata()
>    {
>       remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class);
>       if (remoteBindings == null)
>   ...
>       }
>          else
>          {
>        	 // defaultClientBinding is more accurate that the constant in RemoteBinding 
>              if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) {
>                  binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory());
>              }
>             RemoteBinding[] list = {binding};
>             remoteBindings = new RemoteBindingsImpl(list);
>             advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings);
>          }
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:47:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 20:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21391259.1157158064169.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=comments#action_12342658 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-505:
---------------------------------------------

Good show case for "measure first and optimize based on measurements"

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:47:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 20:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6520371.1157158064308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Ovidiu Feodorov updated JBMESSAGING-505:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.GA)

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 21:51:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 1 Sep 2006 21:51:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-677) EJB3 deployments
 should be bound with rebind instead of bind
In-Reply-To: <7679261.1154618051633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16129049.1157161904249.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-677?page=all ]

William DeCoste closed EJBTHREE-677.
------------------------------------

    Resolution: Done

> EJB3 deployments should be bound with rebind instead of bind
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-677
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-677
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Using bind instead of rebind may cause trouble when the JNDI implementation is persistent (e.g. in an ldap directory) because deploying a previously crashed application will fail. 
> I know that the current situation can also be seen as a feature because the developer cannot deploy two different beans with the same jndi name but this has in my opinion a lesser priority. Further the ejb 2.x stack uses rebind too.
> The request http://jira.jboss.com/jira/browse/EJBTHREE-51 describtes to use Util.rebind()  but in fisheye I saw Util.bind().

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 09:49:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 09:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-296) List and document
 system properties used in JGroups
Message-ID: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>

List and document system properties used in JGroups
---------------------------------------------------

                 Key: JGRP-296
                 URL: http://jira.jboss.com/jira/browse/JGRP-296
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.4


- bind.address
- ignore.bind.address
- jboss.tcpping.initial_hosts
- jboss.partition.udpPort
- jboss.partition.udpGroup
- jboss.mcast.ip.ttl

#1 Collect all system properties used by JGroups
#2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
#3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 10:01:44 2006
From: jira-events at jboss.com (Denis Peyrusaubes (JIRA))
Date: Sat, 2 Sep 2006 10:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-696) Not active
 transaction in a slsb
Message-ID: <14938454.1157205704015.JavaMail.jira@cloud.prod.atl2.jboss.com>

Not active transaction in a slsb
--------------------------------

                 Key: EJBTHREE-696
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-696
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC8 - FD
         Environment: jboss-4.0.4.GA
            Reporter: Denis Peyrusaubes
            Priority: Minor


Calling the setRollBackOnly method in a method of SLSB marked with Required attribute throws a "org.jboss.util.NestedSQLException: Transaction is not active".


-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:01:47 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:01:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-147) Deadlock in
 AsynchViewChangeaHandler
Message-ID: <5073888.1157209307793.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock in AsynchViewChangeaHandler
------------------------------------

                 Key: JBCLUSTER-147
                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-147
             Project: JBoss Clustering
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: JBoss-4.0 (branch)
            Reporter: Bela Ban
         Assigned To: Brian Stansberry


Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads


Name: main
State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
Total blocked: 6  Total waited: 17

Stack trace: 
at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)




Name: AsynchViewChangeHandler Thread
State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
Total blocked: 1  Total waited: 1
 
Stack trace: 
at org.jboss.system.ServiceController.create(ServiceController.java:286)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy46.create(Unknown Source)
at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy47.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
at java.lang.Thread.run(Thread.java:595)


-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:33:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-2) Memory based flow
	control
Message-ID: <12577848.1157211223843.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-2?page=comments#action_12342685 ] 
            
Bela Ban commented on JGRP-2:
-----------------------------

Memory monitoring could be done by (JDK 5 only) java.lang.management.MemoryMXBean, with notifications.

> Memory based flow control
> -------------------------
>
>                 Key: JGRP-2
>                 URL: http://jira.jboss.com/jira/browse/JGRP-2
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Memory and retransmission based flow control protocol. Should be much faster than the current FC
> on a fast network, we can still run out of memory because received_msgs/delivered_msgs becomes very big.
>   Instead of basing FC on the speed of the network, we should also take the number of messages processed
>   (a.k.a delivered_msgs/received_msgs) into account, and only send credits when that number falls below a
>   certain threshold. First: look at the number of received/delivered msgs in the perf test !
>   --> Look into memory-based FC: criteria for sending credits are
>       - available free memory
>       - outstanding retransmission requests (sender sends with each message number of messages sent,
>         receiver keeps track of how many messages received, if diff is > threshold --> pause)
>       - [optional] latency

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:41:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:41:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-297) Use deadlock
 detection (JDK 5) to
 find deadlocks in stress tests or during regular operation
Message-ID: <2972305.1157211703949.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use deadlock detection (JDK 5) to find deadlocks in stress tests or during regular operation
--------------------------------------------------------------------------------------------

                 Key: JGRP-297
                 URL: http://jira.jboss.com/jira/browse/JGRP-297
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


The java.lang.management.ThreadMXBean has a method to check for and (if found) enumerate deadlocked threads (only with simply synchronized locks, jav.util.concurrent locks currently not supported afaik).
This can be run every N seconds, and is useful in both stress testing and possibly also during operation.

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:41:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-297) Use deadlock
 detection (JDK 5)
 to find deadlocks in stress tests or during regular operation
In-Reply-To: <2972305.1157211703949.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8860123.1157211704083.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-297?page=comments#action_12342686 ] 
            
Bela Ban commented on JGRP-297:
-------------------------------

Links: 
- java.lang.management package
- Heinz article: http://www.javaspecialists.co.za/archive/newsletter.do?issue=093&locale=en_US and http://www.javaspecialists.co.za/archive/newsletter.do?issue=093&locale=en_US

> Use deadlock detection (JDK 5) to find deadlocks in stress tests or during regular operation
> --------------------------------------------------------------------------------------------
>
>                 Key: JGRP-297
>                 URL: http://jira.jboss.com/jira/browse/JGRP-297
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> The java.lang.management.ThreadMXBean has a method to check for and (if found) enumerate deadlocked threads (only with simply synchronized locks, jav.util.concurrent locks currently not supported afaik).
> This can be run every N seconds, and is useful in both stress testing and possibly also during operation.

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 16:59:44 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 16:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-435) Large integer
 values in
 decision tables are converted to scientific notation in DRL which cannot be
 parsed
In-Reply-To: <8098647.1155759034300.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21896878.1157230784097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-435?page=all ]

Mark Proctor updated JBRULES-435:
---------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Large integer values in decision tables are converted to scientific notation in DRL which cannot be parsed
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-435
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-435
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Drl Parser/Builder
>            Reporter: Volker Augustin
>         Assigned To: Michael Neale
>
> When a condition column in a decision table contains values like 25000000, this is compiled using the SpreadsheetCompiler into 2.5E7 in the DRL. However, the DRL parser/compiler cannot cope with this notation and exists with a unexpected token "E7" error 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

        


From jira-events at jboss.com  Sat Sep  2 17:03:43 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 17:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-118) Map generated
 .java compilation errors to  drl
Message-ID: <28553369.1157231024002.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-118?page=comments#action_12342695 ] 
            
Mark Proctor commented on JBRULES-118:
--------------------------------------

yup, but you just fixed that :)
Yes its not a nice solution, as runtime errors will still report the wrong line numbers - unless we "clone" errors replacing with correct filename and line numbers - but this can just get messy with stack traces etc. 
You are right that the whole solution is not that nice, but I can't think of any nicer way with execution of compiled code.

> Map generated .java  compilation errors to  drl
> -----------------------------------------------
>
>                 Key: JBRULES-118
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-118
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Bob McWhirter
>             Fix For: 3.1-m3
>
>
> We know the method name for each descr. If we move the params all onto  a  single line we can use indexof to fine the start of each descr' compiled  code. We can then use that  to find the offiset and map the error  to the descr.
> This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors).

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 17:03:44 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 17:03:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-118) Map generated .java
 compilation errors to  drl
Message-ID: <28620590.1157231024127.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-118?page=all ]

Mark Proctor updated JBRULES-118:
---------------------------------

    Assignee: Mark Proctor  (was: Bob McWhirter)

> Map generated .java  compilation errors to  drl
> -----------------------------------------------
>
>                 Key: JBRULES-118
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-118
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m3
>
>
> We know the method name for each descr. If we move the params all onto  a  single line we can use indexof to fine the start of each descr' compiled  code. We can then use that  to find the offiset and map the error  to the descr.
> This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors).

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 17:07:44 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 17:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-379) function with
 another drools
 function call won't compile (either with eclipse compiler or janino)
In-Reply-To: <13656185.1153782491575.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31652477.1157231264141.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-379?page=all ]

Mark Proctor closed JBRULES-379.
--------------------------------

    Fix Version/s: 3.1-m1
       Resolution: Done

FunctionBuilder now uses FunctionFixer.

> function with another drools function call won't compile (either with eclipse compiler or janino)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-379
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-379
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.1
>         Environment: Debian linux
> JDK 5
>            Reporter: Thierry R
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m1
>
>
> function with another drools function call won't compile (either with eclipse compiler or janino)
> with the error msg :
> "Function Compilation error "
> I wrote a DroolsHelper class to work around.

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 19:17:43 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 19:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-118) Map generated .java
 compilation errors to  drl
Message-ID: <10465510.1157239063854.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-118?page=all ]

Mark Proctor closed JBRULES-118.
--------------------------------

    Resolution: Done

> Map generated .java  compilation errors to  drl
> -----------------------------------------------
>
>                 Key: JBRULES-118
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-118
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m3
>
>
> We know the method name for each descr. If we move the params all onto  a  single line we can use indexof to fine the start of each descr' compiled  code. We can then use that  to find the offiset and map the error  to the descr.
> This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors).

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 19:55:43 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Sat, 2 Sep 2006 19:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-211) update user guide to
 include new features
Message-ID: <24593365.1157241343825.JavaMail.jira@cloud.prod.atl2.jboss.com>

update user guide to include new features
-----------------------------------------

                 Key: BPEL-211
                 URL: http://jira.jboss.com/jira/browse/BPEL-211
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documents
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1 beta 2


-Describe the simplified deployment process
-Document time-driven activities

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 01:11:44 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Sun, 3 Sep 2006 01:11:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-589) Fix raw_socket
 performance tests.
In-Reply-To: <28580876.1156453129208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15363683.1157260304057.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-589?page=comments#action_12342704 ] 
            
Ron Sigal commented on JBREM-589:
---------------------------------

One more change was necessary.  The various server threads get a port number for a callback server, but there was only one callbackServerPort variable, and the threads were stepping on each other.  callbackServerPort is now a ThreadLocal variable.

> Fix raw_socket performance tests.
> ---------------------------------
>
>                 Key: JBREM-589
>                 URL: http://jira.jboss.com/jira/browse/JBREM-589
>             Project: JBoss Remoting
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.0.0.GA (Boon)
>
>
> raw_socket performance tests throwing NullPointerException in SocketPerformanceClient.makeInvocation().

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 11:51:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 11:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3619) Deadlock in
 AsynchViewChangeHandler
Message-ID: <4494655.1157298703835.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock in AsynchViewChangeHandler
-----------------------------------

                 Key: JBAS-3619
                 URL: http://jira.jboss.com/jira/browse/JBAS-3619
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Critical
             Fix For: JBossAS-4.0.5.GA


Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads


Name: main
State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
Total blocked: 6 Total waited: 17

Stack trace:
at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)




Name: AsynchViewChangeHandler Thread
State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
Total blocked: 1 Total waited: 1
 
Stack trace:
at org.jboss.system.ServiceController.create(ServiceController.java:286)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy46.create(Unknown Source)
at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy47.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
at java.lang.Thread.run(Thread.java:595) 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 11:53:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 11:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-147) Deadlock in
 AsynchViewChangeaHandler
In-Reply-To: <5073888.1157209307793.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5653068.1157298823893.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-147?page=all ]

Brian Stansberry resolved JBCLUSTER-147.
----------------------------------------

    Resolution: Duplicate Issue

I'll deal with this via JBAS-3619.

> Deadlock in AsynchViewChangeaHandler
> ------------------------------------
>
>                 Key: JBCLUSTER-147
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-147
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss-4.0 (branch)
>            Reporter: Bela Ban
>         Assigned To: Brian Stansberry
>
> Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads
> Name: main
> State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
> Total blocked: 6  Total waited: 17
> Stack trace: 
> at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
> at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
> at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> at org.jboss.Main.boot(Main.java:200)
> at org.jboss.Main$1.run(Main.java:464)
> at java.lang.Thread.run(Thread.java:595)
> Name: AsynchViewChangeHandler Thread
> State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
> Total blocked: 1  Total waited: 1
>  
> Stack trace: 
> at org.jboss.system.ServiceController.create(ServiceController.java:286)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy46.create(Unknown Source)
> at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
> at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
> at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
> at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy47.create(Unknown Source)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
> at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
> at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
> at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
> at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 12:57:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 12:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3619) Deadlock in
 AsynchViewChangeHandler
In-Reply-To: <4494655.1157298703835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30903956.1157302663798.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3619?page=all ]

Brian Stansberry closed JBAS-3619.
----------------------------------

    Resolution: Done

Problem was HAPartitionImpl was holding a lock on its membership listener ArrayList while iterating through it and notifying listeners of  a change event. It now only synchronizes to clone the listener list, and then iterates over the clone.

> Deadlock in AsynchViewChangeHandler
> -----------------------------------
>
>                 Key: JBAS-3619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3619
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads
> Name: main
> State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
> Total blocked: 6 Total waited: 17
> Stack trace:
> at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
> at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
> at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> at org.jboss.Main.boot(Main.java:200)
> at org.jboss.Main$1.run(Main.java:464)
> at java.lang.Thread.run(Thread.java:595)
> Name: AsynchViewChangeHandler Thread
> State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
> Total blocked: 1 Total waited: 1
>  
> Stack trace:
> at org.jboss.system.ServiceController.create(ServiceController.java:286)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy46.create(Unknown Source)
> at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
> at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
> at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
> at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy47.create(Unknown Source)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
> at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
> at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
> at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
> at java.lang.Thread.run(Thread.java:595) 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 13:37:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 13:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9355723.1157305063812.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-296?page=comments#action_12342709 ] 
            
Brian Stansberry commented on JGRP-296:
---------------------------------------

A couple others for MPING, which would want to use a different address/port from any UDP-based channel in the same JVM:

jgroups.mping.mcast_addr
jgroups.mping.mcast_port

Also, a transition from jboss.partition.udpGroup to jgroups.udp.mcast_addr can be done within the AS itself.  All new config files use  jgroups.udp.mcast_addr, but if the -u switch is set both system properties get set, so legacy config files still work.

> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 14:01:43 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Sun, 3 Sep 2006 14:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-502) Create a
 MSSQL persistence manager config
In-Reply-To: <29492968.1155039912398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <656738.1157306503830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-502?page=all ]

Luc Texier resolved JBMESSAGING-502.
------------------------------------

    Resolution: Done


a brand new pm called mssql-persistence-service.xml is not present in src\etc\server\default\deploy in Branch_1_0

I also updated the wiki pages. I created new sections and added pages to explain how to deploy the pm configuration
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessaging



> Create a MSSQL persistence manager config
> -----------------------------------------
>
>                 Key: JBMESSAGING-502
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-502
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Luc Texier
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 14:47:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Sun, 3 Sep 2006 14:47:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-695) support properties
 service in ejb3
In-Reply-To: <18560791.1157141623768.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4648267.1157309263841.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-695?page=all ]

William DeCoste closed EJBTHREE-695.
------------------------------------

    Resolution: Done

> support properties service in ejb3
> ----------------------------------
>
>                 Key: EJBTHREE-695
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-695
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - 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

        


From jira-events at jboss.com  Sun Sep  3 15:45:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 15:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29740313.1157312743819.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-296?page=comments#action_12342714 ] 
            
Brian Stansberry commented on JGRP-296:
---------------------------------------

Also, I prefer what you did with things like jgroups.udp.mcast_addr rather than mcast.addr.  Easier to remember that way -- last element of property name matches the attribute name.  So a convention could be:

jgroups.<protocol name in lower case>.attribute_name

with the second element removed or replaced by something generic if the same system property is used in more than one protocol, e.g.

jgroups.bind_addr  (2nd element removed)

jgroups.mcast.ip_ttl  (2nd element is 'mcast' since the same value is used for both UDP and MPING)


> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 16:47:44 2006
From: jira-events at jboss.com (bugra uytun (JIRA))
Date: Sun, 3 Sep 2006 16:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
Message-ID: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>

hibernate reverse engineering does not set "schema" attribute in .hbm.xml
-------------------------------------------------------------------------

                 Key: JBIDE-359
                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
             Project: JBoss IDE
          Issue Type: Bug
          Components: Hibernate Tools
         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
            Reporter: bugra uytun
         Assigned To: Max Andersen


i set the schema in hibernate.cfg.xml with:

---
<property name="hibernate.default_schema">mySchema</property>
---

after reverse engineering the DB I get the .hbm.xml file

---
...
<hibernate-mapping>
    <class name="com.someclass" table="MY_TABLE">
...
---

notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:

---
org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
---


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 16:49:43 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Sun, 3 Sep 2006 16:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
In-Reply-To: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14135320.1157316583827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-359?page=all ]

Max Andersen closed JBIDE-359.
------------------------------

    Resolution: Rejected

if you don't what it to be the default schema then don't set it as the default schema.

> hibernate reverse engineering does not set "schema" attribute in .hbm.xml
> -------------------------------------------------------------------------
>
>                 Key: JBIDE-359
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>
> i set the schema in hibernate.cfg.xml with:
> ---
> <property name="hibernate.default_schema">mySchema</property>
> ---
> after reverse engineering the DB I get the .hbm.xml file
> ---
> ...
> <hibernate-mapping>
>     <class name="com.someclass" table="MY_TABLE">
> ...
> ---
> notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:
> ---
> org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
> ---

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 16:51:43 2006
From: jira-events at jboss.com (bugra uytun (JIRA))
Date: Sun, 3 Sep 2006 16:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-360) wrong spelling in
 Hibernate Code Generation window
Message-ID: <12128434.1157316703833.JavaMail.jira@cloud.prod.atl2.jboss.com>

wrong spelling in Hibernate Code Generation window
--------------------------------------------------

                 Key: JBIDE-360
                 URL: http://jira.jboss.com/jira/browse/JBIDE-360
             Project: JBoss IDE
          Issue Type: Bug
          Components: Hibernate Tools
         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
            Reporter: bugra uytun
         Assigned To: Max Andersen
            Priority: Trivial


wrong spelling in Hibernate Code Generation window => "Main" tab => "Dectect optimistic lock columns" checkbox.

instead of "Dectect" it should be "Detect"

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 17:59:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 17:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-710) Producer
	clustering support
Message-ID: <1463638.1157320783904.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-710?page=all ]

Julien Viet updated JBPORTAL-710:
---------------------------------

        Fix Version/s:     (was: 2.6 Final)
    Affects Version/s:     (was: 2.4 Final)

> Producer clustering support
> ---------------------------
>
>                 Key: JBPORTAL-710
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-710
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 17:59:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 17:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-264) Login module can
 create missing user
Message-ID: <30225836.1157320784075.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-264?page=all ]

Julien Viet updated JBPORTAL-264:
---------------------------------

    Assignee:     (was: Chris Laprun)

> Login module can create missing user
> ------------------------------------
>
>                 Key: JBPORTAL-264
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-264
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add an option to the ModelLoginModule in order that it creates anuser when it does not exist. This would obviously work in conjonction with another login module placed in front of it that would authenticate username/password. The communication between the two modules would be done by using password stacking.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:01:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32043186.1157320904096.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Julien Viet resolved JBPORTAL-964.
----------------------------------

    Resolution: Cannot Reproduce Bug

2.6 will feature a new theme so that issues cannot be resolved.

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>             Fix For: 2.6 Final
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:01:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-453) Implement
 producer URL writing
Message-ID: <2863190.1157320904259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-453?page=all ]

Julien Viet resolved JBPORTAL-453.
----------------------------------

    Resolution: Duplicate Issue

> Implement producer URL writing
> ------------------------------
>
>                 Key: JBPORTAL-453
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-453
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Polina Alber
>         Assigned To: Chris Laprun
>             Fix For: 2.6 Final
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:05:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-233) User metadata
Message-ID: <31754208.1157321143953.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-233?page=all ]

Julien Viet updated JBPORTAL-233:
---------------------------------

    Component/s: Identity
                     (was: Portal Core)

> User metadata
> -------------
>
>                 Key: JBPORTAL-233
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-233
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>
> The portal defines itw own way to manipulate user. The current interface definition is capable to manipulate users. In particular it is possible to use user properties in a dynamic way. However it is not possible to know what properties are supported. Therefore we need to add metadata to the module in order to know informations about the properties available and supported by the portal.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:05:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:05:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-264) Login module can
 create missing user
Message-ID: <31739921.1157321144126.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-264?page=all ]

Julien Viet updated JBPORTAL-264:
---------------------------------

    Component/s: Identity
                     (was: Portal Core)

> Login module can create missing user
> ------------------------------------
>
>                 Key: JBPORTAL-264
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-264
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add an option to the ModelLoginModule in order that it creates anuser when it does not exist. This would obviously work in conjonction with another login module placed in front of it that would authenticate username/password. The communication between the two modules would be done by using password stacking.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:05:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:05:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-464) LDAP
 implementation of UserModule and RoleModule
Message-ID: <8896631.1157321144349.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-464?page=all ]

Julien Viet updated JBPORTAL-464:
---------------------------------

    Component/s: Identity
                     (was: Portal Core)

> LDAP implementation of UserModule and RoleModule
> ------------------------------------------------
>
>                 Key: JBPORTAL-464
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-464
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.0 Final, 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>         Attachments: MSADLoginModule.zip, org.zip
>
>   Original Estimate: 1 week
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPTL-18) JSR-168
Message-ID: <31089929.1157321267937.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-18?page=all ]

Julien Viet updated JBPTL-18:
-----------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> JSR-168
> -------
>
>                 Key: JBPTL-18
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-18
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> Finish the JSR-168 full impl. These features are not a problem for the compliance and are not widely used

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-677) Secure Portlet
	Modes
Message-ID: <8658435.1157321272534.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-677?page=all ]

Julien Viet updated JBPORTAL-677:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Secure Portlet Modes
> --------------------
>
>                 Key: JBPORTAL-677
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-677
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2 Branch
>            Reporter: Jouni Rajala
>             Fix For: 2.6.Alpha1
>
>
> Request for feature that allows me to secure portlet mode per User's Role. I need this to prevent anonymous and 'normal' users to customize portlets while allowing advanced users to enter into edit mode.
> For me this feature is blocker, because I can't deploy my application to JBoss portal if modes can't be secured.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-464) LDAP
 implementation of UserModule and RoleModule
Message-ID: <3942471.1157321272673.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-464?page=all ]

Julien Viet updated JBPORTAL-464:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> LDAP implementation of UserModule and RoleModule
> ------------------------------------------------
>
>                 Key: JBPORTAL-464
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-464
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.0 Final, 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>         Attachments: MSADLoginModule.zip, org.zip
>
>   Original Estimate: 1 week
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-835) Implement
 WSRPActionContext
 getContentLength, getReader and getInputStream correctly.
Message-ID: <12243695.1157321272783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-835?page=all ]

Julien Viet updated JBPORTAL-835:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Implement WSRPActionContext getContentLength, getReader and getInputStream correctly.
> -------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-835
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-835
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Right now throws UnsupportedOperationException since previous implementation was returning raw information from the SOAP request.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-896) JBoss Portal look
	and feel
Message-ID: <760757.1157321272930.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-896?page=all ]

Julien Viet updated JBPORTAL-896:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> JBoss Portal look and feel
> --------------------------
>
>                 Key: JBPORTAL-896
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-896
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Damon Sicore
>             Fix For: 2.6.Alpha1
>
>
> we need a (rather good and appealing) default look and feel composed
> - theme
> - icons
> - custom css styles : portlet and portal
> additonally we need 2 additional themes.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-730) "Copy" should
 copy the live revision
Message-ID: <29310339.1157321273089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-730?page=all ]

Julien Viet updated JBPORTAL-730:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> "Copy" should copy the live revision
> ------------------------------------
>
>                 Key: JBPORTAL-730
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-730
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.2 Branch
>            Reporter: Thomas Heute
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> The current "copy" feature using Jackrabbit Workspace.copy() seems to copy the latest revision and only that one.
> Jackrabbit implementation won't help here (since it should be faster to do it at this level)
> If we decide to copy a unique revision we should copy the Live version. (can be different from the latest)
> Now the question is: should we copy all revisions or only the live one ?

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-887) Portal UI
 usuability improvements
Message-ID: <22863300.1157321273265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-887?page=all ]

Julien Viet updated JBPORTAL-887:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portal UI usuability improvements
> ---------------------------------
>
>                 Key: JBPORTAL-887
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-887
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Branch
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Roy Russo
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> some stuff that can be improved in UI Usuability
> 1) In Admin Portlet when you add portlet instances to a page the list of them is not sorted anyway so it's hard to fine what you want. Plus possibly with many portlets it will be hard to handle it from drop down list

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-715) Consumer explicit
 property setting mechanism with GUI for property management
Message-ID: <28165776.1157321273424.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-715?page=all ]

Julien Viet updated JBPORTAL-715:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer explicit property setting mechanism with GUI for property management
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-715
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-715
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-808) Check WSRP type
 definition to check for non-nillable values
Message-ID: <15411931.1157321273553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-808?page=all ]

Julien Viet updated JBPORTAL-808:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Check WSRP type definition to check for non-nillable values
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-808
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-808
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 hours
>          Time Spent: 1 hour
>  Remaining Estimate: 3 hours
>
> JBoss WS stack creates default value for nillable WSDL elements. If no valid value is provided for a non-nillable element, this will cause an error about elements being out of sequence.
> Example:
> From wsrp_v1_types.xsd, a valid markup request conforms to the getMarkup element:
> registrationContext (nillable), portletContext, runtimeContext, userContext (nillable), markupParams.
> runtimeContext is non-nillable. If no valid runtimeContext is provided when creating the getMarkup object, the WS stack will not emit an element for runtimeContext whereas one will be for userContext (which is nillable), resulting in the WS complaining about userContext not being in the right position in the sequence.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-705) Consumer implicit
 cloning support
Message-ID: <6355517.1157321273748.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-705?page=all ]

Julien Viet updated JBPORTAL-705:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer implicit cloning support
> ---------------------------------
>
>                 Key: JBPORTAL-705
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-705
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-965) Localization
	Support bug
In-Reply-To: <15499109.1153473071330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14510433.1157321273877.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-965?page=all ]

Julien Viet updated JBPORTAL-965:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Localization Support bug
> ------------------------
>
>                 Key: JBPORTAL-965
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-965
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: windowxp,ie6,charset=zh-ch
>            Reporter: &#21556;&#22869;&#38596;
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-868) Consumer managed
	state testing
Message-ID: <2576092.1157321274037.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-868?page=all ]

Julien Viet updated JBPORTAL-868:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer managed state testing
> ------------------------------
>
>                 Key: JBPORTAL-868
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-868
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I have added InstanceContext.portletCloned(String portletId, byte[] state) method. We need a test case that retrieves the byte array state from the WSRP PortletContext and makes a callback to the InstanceContext.portletCloned method as we must support consumer state management in our WSRP consumer.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-637) Portlet Container
 test cases beyond "PLT.F TCK Assertions"
Message-ID: <18801427.1157321274179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-637?page=all ]

Julien Viet updated JBPORTAL-637:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portlet Container test cases beyond "PLT.F TCK Assertions"
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-637
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 hours
>
> Implement portlet container test cases which are not in scope of Portlet Specification TCK Assertions. 
> So any specific test cases which don't belong to http://jira.jboss.com/jira/browse/JBPORTAL-636

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-466)
 JBossRenderRequest needs to
 provide access to the current PortalTheme
Message-ID: <7479912.1157321274308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-466?page=all ]

Julien Viet updated JBPORTAL-466:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> JBossRenderRequest needs to provide access to the current PortalTheme
> ---------------------------------------------------------------------
>
>                 Key: JBPORTAL-466
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-466
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Final
>            Reporter: Martin Holzner
>             Fix For: 2.6.Alpha1
>
>
> This is a feature that Roy needs in one of the CM portlets. 
> There is a temp fix for this already in the RenderPageCommand , but it is a hack. It needs to be revisited! 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-857) Deal with non
 standard Locales better
Message-ID: <14736904.1157321274432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-857?page=all ]

Julien Viet updated JBPORTAL-857:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Deal with non standard Locales better
> -------------------------------------
>
>                 Key: JBPORTAL-857
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-857
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Per the WSRP Spec regarding UnsupportedLocale fault:
> The Portlet does not support generating markup for the requested locale. Since the Portlet is not required to generate markup in the requested locale, a Portlet returning this fault message is indicating that it processes locales in a stricter manner and has no markup for the requested locales. The Consumer can treat this as a specialization of the OperationFailed fault message and does not have to retry getting the markup in other locales.
> Currently, LocaleInfo throws an IllegalArgumentException if the locale is not standard which gets wrapped into an OperationFailedFault at the handler level. We should deal with locale errors better and maybe be more lenient as to what we accept.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-435) Request dumper
	interceptor
Message-ID: <11527757.1157321274573.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-435?page=all ]

Julien Viet updated JBPORTAL-435:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Request dumper interceptor
> --------------------------
>
>                 Key: JBPORTAL-435
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-435
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Server
>            Reporter: Julien Viet
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Ala tomcat : allows to see what parameters a portlet receive

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-372) Basic Publish
 Approval Workflow
Message-ID: <24741810.1157321274795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-372?page=all ]

Julien Viet updated JBPORTAL-372:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Basic Publish Approval Workflow
> -------------------------------
>
>                 Key: JBPORTAL-372
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-372
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: James Williams
>         Assigned To: Roy Russo
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> Optional feature which mandates that  content changes must flow through a simple approval process that involves a Publisher and one or more Managers. Once the publisher makes a content change an email approval request should be sent to the manager list. The content change will not be made available to readers until all Managers approve the change.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-847) Identify common
 conversion
 methods (from Set<Mode> to String[] for ex) and put them in a utility class
Message-ID: <32274435.1157321274934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-847?page=all ]

Julien Viet updated JBPORTAL-847:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Identify common conversion methods (from Set<Mode> to String[] for ex) and put them in a utility class
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-847
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-847
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> There are several similar versions of such code. Try to find some time and gather all this code in a single spot.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:55 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-528) Management
 portlet creating inaccessible instance with empty name field
Message-ID: <24013160.1157321275336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-528?page=all ]

Julien Viet updated JBPORTAL-528:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Management portlet creating inaccessible instance with empty name field
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-528
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-528
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> as in forum post:
> "From the management portlet (page view), I clicked the button "Add instance" without entering anything in the text field. It created a blank portlet window. Since it has no names, there are no links associated with it. As a result, I can't delete it."

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:55 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-635) Portlet Container
	tests
Message-ID: <19336025.1157321275454.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-635?page=all ]

Julien Viet updated JBPORTAL-635:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portlet Container tests
> -----------------------
>
>                 Key: JBPORTAL-635
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-635
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 days, 7 hours, 30 minutes
>
> Implement full range of tests for portlet container
> - TCK Assertions from Portlet Specification
> - Additional test based on portlet specification to cover any specific behavior of container

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:58 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-467) Login page needs
 to use the theme of the requested portal
Message-ID: <28748039.1157321278760.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-467?page=all ]

Julien Viet updated JBPORTAL-467:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Login page needs to use the theme of the requested portal
> ---------------------------------------------------------
>
>                 Key: JBPORTAL-467
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-467
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Martin Holzner
>             Fix For: 2.6.Alpha1
>
>
> The Login.jsp that the web.xml's form login points to is in the portal-server.war. 
> A call to this jsp does not go through any of the stacks in the portal core, and hence there is no portal or page object available to determine the currently set property for the selected theme. As a result, the Login jsp cannot be styled in synch with the rest of the portal. 
> In the context of having a synchronized look and feel throughout a portal, the login needs to be able to select the same theme as the portal that was requested, so that the login fits seemlessly into the UI flow. 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:58 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-767) ERROR
 [org.apache.myfaces.portlet.MyFacesGenericPortlet]
Message-ID: <1577106.1157321278926.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-767?page=all ]

Julien Viet updated JBPORTAL-767:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> ERROR [org.apache.myfaces.portlet.MyFacesGenericPortlet]
> --------------------------------------------------------
>
>                 Key: JBPORTAL-767
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-767
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final
>         Environment: Mac OS X, jboss-portal-2.2.1RC2-bundled
>            Reporter: Leonard Sitongia
>             Fix For: 2.6.Alpha1
>
>
> (I'm using jboss-portal-2.2.1RC2-bundled, but I'm building and deploying 2.4 from CVS into it.)
> I've used management to create a new page (tab) at the top level, same as default.  I add a few portlets to that, including navigation, user and the CMS content one.  I remove the CMS content one.  Thereafter, when I use management to enter the default portal (by clicking on "default" in the management portlet's navigation tree on the left), I get an exception, and the management portlet is not rendered on the page.
> 2006-03-22 08:26:57,497 ERROR [org.apache.myfaces.portlet.MyFacesGenericPortlet]
>  The portlet threw an exception
> javax.portlet.PortletException: /WEB-INF/jsp/management/index.xhtml @100,58 rend
> ered="#{!empty node.children}": org.jboss.portal.core.portlet.management.LazyPor
> talObjectTreeNode
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromL
> ifecycle(MyFacesGenericPortlet.java:254)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesG
> enericPortlet.java:400)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGeneri
> cPortlet.java:266)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContain
> er.java:552)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.j
> ava:464)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInv
> ocation.java:79)
>         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.j
> ava:142)
> ...
> Thanks,
> ==Leonard

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:59 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-660) Test servlet and
 filter commands
Message-ID: <7066090.1157321279068.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-660?page=all ]

Julien Viet updated JBPORTAL-660:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test servlet and filter commands
> --------------------------------
>
>                 Key: JBPORTAL-660
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-660
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Server
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:59 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-717) Consumer
	localization
Message-ID: <29422501.1157321279231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-717?page=all ]

Julien Viet updated JBPORTAL-717:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer localization
> ---------------------
>
>                 Key: JBPORTAL-717
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-717
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-530) Null Pointer
 Exception in MyFacesGenericPortlet
Message-ID: <619771.1157321280020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-530?page=all ]

Julien Viet updated JBPORTAL-530:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Null Pointer Exception in MyFacesGenericPortlet
> -----------------------------------------------
>
>                 Key: JBPORTAL-530
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-530
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Jboss 4.0.3 SP1 - portal 2.0.1 RC3
>            Reporter: Stefan Tausendpfund
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>         Attachments: DuplicatePortletTestWeb.tgz
>
>
> Hello,
> the initial post is from the Jboss portal forum. 
> I repost it to attach a sample application showing this error.
> <snip>
> Hello,
> we created an portal application on JBoss Server 4.0.3SP1 with portal 2.0.1RC3 using myfaces MyFacesGenericPortlet. We have several pages and several portlets in one page. One portlet is present in all pages. If I make an action on this portlet (portletwindow0) and switch the page (portletwindow1) i get an NPE in the facesRender method of the MyFacesGenericPortlet.
> The lookup of the faces context with
> ServletFacesContextImpl facesContext = (ServletFacesContextImpl)request.
> getPortletSession().
> getAttribute(CURRENT_FACES_CONTEXT);
> returns a null object and the following statement
> if (facesContext.getResponseComplete()) return;
> fails.
> On first entry of doView the getAttribure looks for an Attribute:
> javax.portlet.p..<portletwindow0>?org.apache.myfaces.portlet.MyFacesGenericPortlet.CURRENT_FACES_CONTEXT
> After switching the page it looks for
> javax.portlet.p..<portletwindow1>?org.apache.myfaces.portlet.MyFacesGenericPortlet.CURRENT_FACES_CONTEXT
> but the facescontext is still with the key window0 in the session.
> Using the same window name in different pages for the same portlet leeds to a portal error. 
> <snap>
> best regards
>    Stefan Tausendpfund

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-522) Edit modes and
 window states in the portalobject manager
Message-ID: <31970112.1157321280151.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-522?page=all ]

Julien Viet updated JBPORTAL-522:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Edit modes and window states in the portalobject manager
> --------------------------------------------------------
>
>                 Key: JBPORTAL-522
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-522
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-328) CMS security
Message-ID: <688501.1157321280357.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-328?page=all ]

Julien Viet updated JBPORTAL-328:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> CMS security
> ------------
>
>                 Key: JBPORTAL-328
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-328
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Improve the current CMS security.
> No check is done at the CMSPortlet level, this is a important missing feature.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-663) Test instance
	container
Message-ID: <20419069.1157321280484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-663?page=all ]

Julien Viet updated JBPORTAL-663:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test instance container
> -----------------------
>
>                 Key: JBPORTAL-663
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-663
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-393) Security audit/log
Message-ID: <4108618.1157321280616.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-393?page=all ]

Julien Viet updated JBPORTAL-393:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Security audit/log
> ------------------
>
>                 Key: JBPORTAL-393
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-393
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Noel Rocher
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> Provide a mean to log and see all security problems that occur.
>  

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-711) Producer URL
 templating support
Message-ID: <25332178.1157321280789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-711?page=all ]

Julien Viet updated JBPORTAL-711:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer URL templating support
> -------------------------------
>
>                 Key: JBPORTAL-711
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-711
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:01 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-861) Brazilian
 Portguese Portal localization (draft version)
Message-ID: <5470959.1157321281445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-861?page=all ]

Julien Viet updated JBPORTAL-861:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Brazilian Portguese Portal localization (draft version)
> -------------------------------------------------------
>
>                 Key: JBPORTAL-861
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-861
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final
>         Environment: JPortal 2.2.1 RC2
>            Reporter: sumersoft sumersoft
>            Priority: Trivial
>             Fix For: 2.6.Alpha1
>
>         Attachments: Resource_pt_BR.properties
>
>
> Brazilian Portuguese Portal Core translation

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:01 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-895) update myfaces
 libraries to newest release
Message-ID: <28826403.1157321281612.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-895?page=all ]

Julien Viet updated JBPORTAL-895:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> update myfaces libraries to newest release
> ------------------------------------------
>
>                 Key: JBPORTAL-895
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-895
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>         Environment: any
>            Reporter: Danijel Jevtic
>            Priority: Critical
>             Fix For: 2.6.Alpha1
>
>
> Could you please upgrade to the newest tomahawk-version?!

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:01 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-983) Upload of large
	files fails.
In-Reply-To: <24473425.1155836711730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25129724.1157321281898.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-983?page=all ]

Julien Viet updated JBPORTAL-983:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)
                       (was: 2.4.1 Final)

> Upload of large files fails.
> ----------------------------
>
>                 Key: JBPORTAL-983
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-983
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP, JDK 1.5, JBoss AS 4.0.4GA
>            Reporter: Peter Johnson
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Using the CMS Admin portlet, I attempted to upload a zip file into a directory, as per section 3.2.9 of the User Guide. Initially I tried a zip ofabout 6MB containing many files, and eventually got down to a a zip file of about 500M with only a single Word document inside.  The upload failed and an "SQLException: could not reset reader" error appeared (see forum post for stack trace).
> I am, however, able to upload very small zip files.
>  

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-667) Refactor the
 command invocation framework
Message-ID: <4039670.1157321282038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-667?page=all ]

Julien Viet updated JBPORTAL-667:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

>  Refactor the command invocation framework
> ------------------------------------------
>
>                 Key: JBPORTAL-667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-667
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> similarly to the component invocation framework : use a Result object and an handler to decouple the action performed within the server and the action following this action 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-536) Add a
 display-name property
 per portal object that contains a i18n name for displaying object
Message-ID: <10147024.1157321282250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-536?page=all ]

Julien Viet updated JBPORTAL-536:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Add a display-name property per portal object that contains a i18n name for displaying object
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-536
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-536
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-708) Producer simple
 level support (full portlet management interface support)
Message-ID: <1202610.1157321282523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-708?page=all ]

Julien Viet updated JBPORTAL-708:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer simple level support (full portlet management interface support)
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-708
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-708
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-859) Suport portlet
 which use GET method in forms.
Message-ID: <14519780.1157321282769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-859?page=all ]

Julien Viet updated JBPORTAL-859:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Suport portlet which use GET method in forms.
> ---------------------------------------------
>
>                 Key: JBPORTAL-859
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-859
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We probably need to add an element similar to remotable to the jboss portlet descriptors...
> From WSRP spec (10.2.4 Method=get in HTML forms):
> User-Agents often throw away any query string from the URL indicated with the form's action attribute when generating the URL they will activate when the form's method is "get". This is the simplest means for them to generate a valid query string. The difficulty this causes is that Consumer's often prefer to store the information they will use when a portlet URL is activated as query string parameters. As a result, Portlets that include HTML forms with method=get in their markup MUST specify usesMethodGet as "true" in their PortletDescription. Consumers choosing to use such Portlets need to format their portlet URLs such that portlet URL activations are processed correctly, regardless of whether Consumer or Producer URL writing is in use.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-504) Migrate the
 features present
 in the UserPortlet on the UserModule as they govern how the service is more
 or less behaves
Message-ID: <27231915.1157321282990.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-504?page=all ]

Julien Viet updated JBPORTAL-504:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Migrate the features present in the UserPortlet on the UserModule as they govern how the service is more or less behaves
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-504
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-504
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Branch, 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-770) Add constant to
 identify default locale when none is given for code requiring locale
Message-ID: <3258957.1157321283186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-770?page=all ]

Julien Viet updated JBPORTAL-770:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Add constant to identify default locale when none is given for code requiring locale
> ------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-770
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-770
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There are several spots where locales are needed and not always available. It is not clear at this point if the default locale should be Locale.ENGLISH or the user's default locale (Locale.getDefault()). Creating a constant (in PortalConstants e.g.) to encapsulate which "default" locale to use should help.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-746) Enhance
	URLVisitor interface
Message-ID: <10409167.1157321283372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-746?page=all ]

Julien Viet updated JBPORTAL-746:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Enhance URLVisitor interface
> ----------------------------
>
>                 Key: JBPORTAL-746
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-746
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2.1 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> Improve URLVisitor and make the startDir method returns a boolean so the visitor can state if it wants to visit the children or just continue.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-707) Consumer
 registration interface
Message-ID: <10740029.1157321283545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-707?page=all ]

Julien Viet updated JBPORTAL-707:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer registration interface
> -------------------------------
>
>                 Key: JBPORTAL-707
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-707
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 5 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-842) Protect each
 Producer method with a check of the registration
Message-ID: <33195289.1157321283838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-842?page=all ]

Julien Viet updated JBPORTAL-842:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Protect each Producer method with a check of the registration
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-842
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-842
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 hours
>          Time Spent: 2 hours
>  Remaining Estimate: 1 hour
>
> See MarkupHandler.getMarkup for how it could be done. Possible implementations: use a dynamic proxy on the Producer impl, use AOP, do it manually...

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-910) On 2.4 release
 migration application should be exposed as separate binary
Message-ID: <33081466.1157321284048.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-910?page=all ]

Julien Viet updated JBPORTAL-910:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> On 2.4 release migration application should be exposed as separate binary
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-910
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-910
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Migration
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Rali Genova
>             Fix For: 2.6.Alpha1
>
>
> When 2.4 will be released we should expose Migration Application as separate pre-build web application archive
> It can be placed either at
> - portletswap
> - portal download area at sourceforge
> - both above :)
> and will enable people to avoid building it from sources.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-538) CMSPortlet
 displays only in
 default page when link is clicked on a different page.
Message-ID: <14891344.1157321284313.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-538?page=all ]

Julien Viet updated JBPORTAL-538:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> CMSPortlet displays only in default page when link is clicked on a different page.
> ----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-538
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-538
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.2 Final, 2.4 Final
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> As mentioned here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3914462

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-894) Add support for
 WSRP resources.
Message-ID: <6628023.1157321284443.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-894?page=all ]

Julien Viet updated JBPORTAL-894:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Add support for WSRP resources.
> -------------------------------
>
>                 Key: JBPORTAL-894
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-894
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPTL-19) PLT.5.2.4.4
 Exceptions During Request Handling : temporary unavailability
Message-ID: <26031721.1157321284557.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-19?page=all ]

Julien Viet updated JBPTL-19:
-----------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> PLT.5.2.4.4 Exceptions During Request Handling : temporary unavailability
> -------------------------------------------------------------------------
>
>                 Key: JBPTL-19
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-19
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-633) Update core
 packaging so it is
 possible to deploy management apps in a separate war that contains tomahawk
Message-ID: <22919969.1157321284674.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-633?page=all ]

Julien Viet updated JBPORTAL-633:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Update core packaging so it is possible to deploy management apps in a separate war that contains tomahawk
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-633
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-633
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-630) Portal name
Message-ID: <17938967.1157321284878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-630?page=all ]

Julien Viet updated JBPORTAL-630:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portal name
> -----------
>
>                 Key: JBPORTAL-630
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-630
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryszard Kozmik
>         Assigned To: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> I need this: req.getPortalContext().getProperty("org.jboss.portal.property.name"));
> to be able to create root link in JBoss Forums.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-821) Find out to
 properly bind property descriptions to schemas
Message-ID: <26049916.1157321285017.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-821?page=all ]

Julien Viet updated JBPORTAL-821:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Find out to properly bind property descriptions to schemas
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-821
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-821
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> In RegistrationTestCase:
> PropertyDescription regProp = new PropertyDescription("regProp", new QName("ns1:LocalizedString"),
>          new LocalizedString("en", null, "Registration Property"), null, null);
> The second parameter of the PropertyDescription constructor is a QName indicating the XSD type of the property. However, the namespace prefix must be bound to a URN somehow. Right now, we're using a hack: ns1:LocalizedString is used since it is a WSRP-defined type. We also use ns1 as the namespace prefix since this is the prefix assigned to the WSRP type namespace which allows the WS stack to find the type. However, this is obvious that this is not the correct way to do it and this will have to be addressed for 2.6.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-709) Producer caching
	support
Message-ID: <29574324.1157321285180.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-709?page=all ]

Julien Viet updated JBPORTAL-709:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer caching support
> ------------------------
>
>                 Key: JBPORTAL-709
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-709
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-718) Expose monitoring
 informations for JBoss ON
Message-ID: <18103358.1157321285379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-718?page=all ]

Julien Viet updated JBPORTAL-718:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Expose monitoring informations for JBoss ON
> -------------------------------------------
>
>                 Key: JBPORTAL-718
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-718
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-264) Login module can
 create missing user
Message-ID: <9325526.1157321285552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-264?page=all ]

Julien Viet updated JBPORTAL-264:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Login module can create missing user
> ------------------------------------
>
>                 Key: JBPORTAL-264
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-264
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add an option to the ModelLoginModule in order that it creates anuser when it does not exist. This would obviously work in conjonction with another login module placed in front of it that would authenticate username/password. The communication between the two modules would be done by using password stacking.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-955) Use globally
 unique (i.e.
 prefixed by org.jboss.portal for ex.) session/invocation attribute names to
 avoid collisions.
In-Reply-To: <23627303.1152885431306.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27035623.1157321285680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-955?page=all ]

Julien Viet updated JBPORTAL-955:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Use globally unique (i.e. prefixed by org.jboss.portal for ex.) session/invocation attribute names to avoid collisions.
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-955
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-955
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-659) Test web app
	instrumentation
Message-ID: <2790211.1157321285810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-659?page=all ]

Julien Viet updated JBPORTAL-659:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test web app instrumentation
> ----------------------------
>
>                 Key: JBPORTAL-659
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-659
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Server
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-957) Mutliple versions
 of languages in language drop-down in user profile
In-Reply-To: <9192030.1152893351367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5216128.1157321285924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-957?page=all ]

Julien Viet updated JBPORTAL-957:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Mutliple versions of languages in language drop-down in user profile
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-957
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-957
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-233) User metadata
Message-ID: <21785941.1157321286070.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-233?page=all ]

Julien Viet updated JBPORTAL-233:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> User metadata
> -------------
>
>                 Key: JBPORTAL-233
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-233
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> The portal defines itw own way to manipulate user. The current interface definition is capable to manipulate users. In particular it is possible to use user properties in a dynamic way. However it is not possible to know what properties are supported. Therefore we need to add metadata to the module in order to know informations about the properties available and supported by the portal.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-765) Portlet
 Specification 1.0 API test cases
Message-ID: <25454277.1157321286188.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-765?page=all ]

Julien Viet updated JBPORTAL-765:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portlet Specification 1.0 API test cases
> ----------------------------------------
>
>                 Key: JBPORTAL-765
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-765
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 1 hour
>
> Implement test cases for javax.portlet.* classes - Portlet Specification 1.0 API. 
> Test cases should not double assertions already done in:
> Portlet Specification 1.0 "PLT.F TCK Assertions" - (http://jira.jboss.com/jira/browse/JBPORTAL-636)
> Portlet Container test cases beyond "PLT.F TCK Assertions" - (http://jira.jboss.com/jira/browse/JBPORTAL-637)
> This test should assert API contracts like - 'null' argument - IllegalArgumentException is thrown. All implementation or behavioral tests should be done in EXT part (http://jira.jboss.com/jira/browse/JBPORTAL-637)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-860) Update DTDs to
 reflect changes in descriptors.
Message-ID: <590784.1157321286309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-860?page=all ]

Julien Viet updated JBPORTAL-860:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Update DTDs to reflect changes in descriptors.
> ----------------------------------------------
>
>                 Key: JBPORTAL-860
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-860
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Update and document changes. Should we move to XSD since some of the DTD elements don't seem to reflect the internal structure of descriptors.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-283) WSRP producer
Message-ID: <30515714.1157321286705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-283?page=all ]

Julien Viet updated JBPORTAL-283:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> WSRP producer
> -------------
>
>                 Key: JBPORTAL-283
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-283
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>
> Compliant implementation of WSRP producer.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-662) Test portal
	object container
Message-ID: <21028151.1157321286854.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-662?page=all ]

Julien Viet updated JBPORTAL-662:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test portal object container
> ----------------------------
>
>                 Key: JBPORTAL-662
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-662
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-839) Support
 UploadContext in getMarkup
Message-ID: <18378241.1157321286983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-839?page=all ]

Julien Viet updated JBPORTAL-839:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Support UploadContext in getMarkup
> ----------------------------------
>
>                 Key: JBPORTAL-839
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-839
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:07 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-532) Define CMS
	security
Message-ID: <31148253.1157321287192.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-532?page=all ]

Julien Viet updated JBPORTAL-532:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Define CMS security
> -------------------
>
>                 Key: JBPORTAL-532
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-532
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Explore the different possbilities of the cms security :
> - define what resources are secured (it should be directories and content)
> - define the security model : the different actions on nodes and their relationship accross the resources (i.e what implies what between different resources)
> - see if the new portal security module can handle that
> - where to apply runtime checks

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:07 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-438) Preference Values
 whose length is greater than 255 characters cannot be saved
Message-ID: <11751787.1157321287329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-438?page=all ]

Julien Viet updated JBPORTAL-438:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Preference Values whose length is greater than 255 characters cannot be saved
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-438
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-438
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.0 Final, 2.0 Branch, 2.4 Final, 2.2 Branch
>         Environment: Windows 2000, JBAS 4.02
>            Reporter: Dennis Meers
>             Fix For: 2.6.Alpha1
>
>
> If you create a portlet that supports EDIT mode and a logged-in user edits a preference, if the value they put in has more than 255 chars, an error occurs.  This is because the table that saves user preference values (jbp_user_pref_value) has a column called 'jbp_value' that is defined as 'VARCHAR(255)'.
> I don't know if the portlet spec defines how many characters are allowed in a preference value, but 255 characters seems small for some portlets.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-337) remove the
 unnecessary and add necessary operations from UserPortlet
Message-ID: <10394589.1157321288198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-337?page=all ]

Julien Viet updated JBPORTAL-337:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> remove the unnecessary and add necessary operations from UserPortlet
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-337
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-337
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Branch
>         Environment: Linux, PostgreSQL, AS 4.0.2
>            Reporter: Yang
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: UserPortlet.diff
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> For core/src/main/org/jboss/portal/core/portlet/user/UserPortlet.java, the operations like SHOW_LOGIN and SHOW_MENU shouldn't be included in UserPortlet. 
> However, operations like FORGETPASSWORD and ACTIVATEACCOUNT should be included. 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-880) Move
 PortalDeployment classes to JBoss XB
Message-ID: <5126643.1157321288329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-880?page=all ]

Julien Viet updated JBPORTAL-880:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Move PortalDeployment classes to JBoss XB
> -----------------------------------------
>
>                 Key: JBPORTAL-880
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-880
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 days
>          Time Spent: 5 hours
>  Remaining Estimate: 2 days, 3 hours
>
> Portal deployment files are currently "manually" parsed via the common.util.XML class. Leveraging JBoss XB should allow for easier maintenance and possibly speed.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-977) 403 error when
 logging in as admin with LDAP
In-Reply-To: <13281047.1154637371578.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29278203.1157321288441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-977?page=all ]

Julien Viet updated JBPORTAL-977:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)
                       (was: 2.4.1 Final)

> 403 error when logging in as admin with LDAP
> --------------------------------------------
>
>                 Key: JBPORTAL-977
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-977
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>         Environment: Portal 2.4 CR3 bundled
>            Reporter: Kevin Barfield
>             Fix For: 2.6.Alpha1
>
>
> A 403 error is shown when logging in as admin using LDAP.  Open a new browser, and now you are logged in.  Same issue with logout.  Logging in as a regular user is fine.
> Here is the login config:
> <policy>
>    <!-- For the JCR CMS -->
>    <application-policy name="cms">
>       <authentication>
>          <login-module code="org.apache.jackrabbit.core.security.SimpleLoginModule" flag="required"/>
>       </authentication>
>    </application-policy>
>    
>    <application-policy name="portal">
>       <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="required">
>                             <module-option name="java.naming.factory.initial"> 
>                                 com.sun.jndi.ldap.LdapCtxFactory
>                                 </module-option>
>                             <module-option name="java.naming.provider.url">
>                                 ldap://localhost/
>                             </module-option>
>                             <module-option name="java.naming.security.authentication">
>                                 simple
>                             </module-option>
>                             <module-option name="java.naming.security.principal">
>       		       cn=Manager,dc=example,dc=com
>                             </module-option>
>                             <module-option name="java.naming.security.credentials">
>       		        secret
>                             </module-option>
>                             <module-option name="principalDNPrefix">cn=</module-option>                    
>                             <module-option name="principalDNSuffix">
>                                 ,ou=people,dc=example,dc=com
>                             </module-option>
>                         <module-option name="password-stacking">useFirstPass</module-option>
>                             <module-option name="rolesCtxDN">
>                                 ou=groups,dc=example,dc=com
>                             </module-option>
>                             <module-option name="uidAttributeID">member</module-option>
>                             <module-option name="matchOnUserDN">true</module-option>
>                             <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false </module-option>
>          <!--
>          <login-module code="org.jboss.portal.identity.auth.IdentityLoginModule" flag="required">
>             <module-option name="unauthenticatedIdentity">guest</module-option>
>             <module-option name="userModuleJNDIName">java:/portal/UserModule</module-option>
>             <module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option>
>             <module-option name="additionalRole">Authenticated</module-option>
>             <module-option name="password-stacking">useFirstPass</module-option>
>             -->
>          </login-module>
>       </authentication>
>    </application-policy>
> </policy>

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-455) Relax portlet
 security roles declaration
Message-ID: <1303531.1157321288590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-455?page=all ]

Julien Viet updated JBPORTAL-455:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Relax portlet security roles declaration
> ----------------------------------------
>
>                 Key: JBPORTAL-455
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-455
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.0 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> Today when a portlet uses the req.isUserInRole(String roleName), this role must be declared in the portlet.xml otherwise the method returns false.
> <portlet>
>    ...
>    <security-role-ref>
>       <role-name>Admin</role-name>
>    </security-role-ref>
>    ...
> </portlet>
> This is what the portlet spec tells to do.
> But it could be possible to avoid this declaration and let all the role checks pass through and delegate the call to the servlet container when configuring jboss portal
> in a certain mode (at server level or webapp level)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-558) Navigation with
 JSF/Facelets broken with multiple portlets in one page
Message-ID: <28267268.1157321289149.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-558?page=all ]

Julien Viet updated JBPORTAL-558:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Navigation with JSF/Facelets broken with multiple portlets in one page
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-558
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-558
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>         Environment: Linux Red Hat Enterprise Server 4 64 Bit, JDK 1.5.0_06
>            Reporter: gressho
>             Fix For: 2.6.Alpha1
>
>
> Navigation results in JSF/Facelet appear allways in the first portlet of the page. The "result" is the same, but "from" and "to" aren't.
> Everything works correct with JSF/JSP.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-875) Test WSRP
 implementation conformance
Message-ID: <16686756.1157321289273.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-875?page=all ]

Julien Viet updated JBPORTAL-875:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test WSRP implementation conformance
> ------------------------------------
>
>                 Key: JBPORTAL-875
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-875
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Critical
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days
>  Remaining Estimate: 0 minutes
>
> Run WSRPtk to test implementation conformance.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-822) Ensure that
 producer is back
 to a default state before the beginning of each test.
Message-ID: <29255109.1157321289399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-822?page=all ]

Julien Viet updated JBPORTAL-822:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Ensure that producer is back to a default state before the beginning of each test.
> ----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-822
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-822
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Make sure that producer is in a correct neutral state before the beginning of each test (been tracking a test issue for a couple of hours that was due to the producer not being in the expected state :( )...

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-712) Producer
 persistent local state
Message-ID: <25207537.1157321289565.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-712?page=all ]

Julien Viet updated JBPORTAL-712:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer persistent local state
> -------------------------------
>
>                 Key: JBPORTAL-712
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-712
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:10 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-768) Russian Portal
 localization (draft version)
Message-ID: <25253025.1157321290022.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-768?page=all ]

Julien Viet updated JBPORTAL-768:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Russian Portal localization (draft version)
> -------------------------------------------
>
>                 Key: JBPORTAL-768
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-768
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final
>         Environment: JPortal 2.2.1 RC2
>            Reporter: Mike Khlu
>            Priority: Trivial
>             Fix For: 2.6.Alpha1
>
>         Attachments: Resource_ru.properties, Resource_ru.properties
>
>
> I'm translate all rows. But portal use only 30% from all strings. i18n may be buggy.
> I think than you can put this file to you future portal releases/

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:10 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-714) Consumer medium
 level support (full portlet management interface support)
Message-ID: <15389798.1157321290172.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-714?page=all ]

Julien Viet updated JBPORTAL-714:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer medium level support (full portlet management interface support)
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-714
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-714
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:17:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9985530.1157321863959.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Julien Viet reopened JBPORTAL-964:
----------------------------------

      Assignee: Roy Russo
             
To be fixed in 2.4.1 actually

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:17:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:17:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9268689.1157321864106.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Julien Viet updated JBPORTAL-964:
---------------------------------

    Fix Version/s: 2.4.1 Final
                       (was: 2.6 Final)

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:21:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-991) UI for user
	creation of pages
In-Reply-To: <7869311.1156184621943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27085329.1157322103846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-991?page=all ]

Roy Russo updated JBPORTAL-991:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI for user creation of pages
> -----------------------------
>
>                 Key: JBPORTAL-991
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-991
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>
> Allow users to create and define page properties.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:23:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:23:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-992) UI for user
	editting of pages
In-Reply-To: <5304149.1156184740617.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9439867.1157322223789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-992?page=all ]

Roy Russo updated JBPORTAL-992:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI for user editting of pages
> -----------------------------
>
>                 Key: JBPORTAL-992
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-992
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1017) Submenu support
 in NavigationPortlet
In-Reply-To: <8700605.1157138144292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12474666.1157322344257.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1017?page=all ]

Roy Russo updated JBPORTAL-1017:
--------------------------------

    Fix Version/s: 2.6.Alpha1

> Submenu support in NavigationPortlet
> ------------------------------------
>
>                 Key: JBPORTAL-1017
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1017
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-825) Usability
 improvements in Admin UI
Message-ID: <11706170.1157322344396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-825?page=all ]

Roy Russo updated JBPORTAL-825:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> Usability improvements in Admin UI
> ----------------------------------
>
>                 Key: JBPORTAL-825
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-825
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Address usability issues with interface redesign, tooltips, and help mode in management portlet.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1007) Fix drag & drop
 code to work in Konqueror
In-Reply-To: <2383186.1156994624285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10723874.1157322344552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1007?page=all ]

Roy Russo updated JBPORTAL-1007:
--------------------------------

    Affects Version/s: 2.6.Alpha1

> Fix drag & drop code to work in Konqueror
> -----------------------------------------
>
>                 Key: JBPORTAL-1007
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1007
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Konqueror
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> check with Tomek.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-994) UI enhancements
 to bundled portlets
In-Reply-To: <28222267.1156185580797.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20121212.1157322344673.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-994?page=all ]

Roy Russo updated JBPORTAL-994:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI enhancements to bundled portlets
> -----------------------------------
>
>                 Key: JBPORTAL-994
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-994
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> userportlet
> roleportlet
> cmsadmin
> cms content
> managementportlet

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1006) Fix drag & drop
 code to work in IE
In-Reply-To: <9281802.1156994623979.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26976772.1157322344842.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1006?page=all ]

Roy Russo updated JBPORTAL-1006:
--------------------------------

    Affects Version/s: 2.6.Alpha1

> Fix drag & drop code to work in IE
> ----------------------------------
>
>                 Key: JBPORTAL-1006
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1006
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Internet Explorer
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Drag&drop javascript code currently works fine in Firefox. Check with Tomek.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-989) Create new
	Default Theme
In-Reply-To: <30876246.1156181504563.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9017855.1157322344972.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-989?page=all ]

Roy Russo updated JBPORTAL-989:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> Create new Default Theme
> ------------------------
>
>                 Key: JBPORTAL-989
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-989
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Use mockup v3 to generate CSS theme.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:45 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-990) AJAX lib to allow
 user positioning of windows
In-Reply-To: <25250425.1156182220833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13368241.1157322345248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-990?page=all ]

Roy Russo updated JBPORTAL-990:
-------------------------------

    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> AJAX lib to allow user positioning of windows
> ---------------------------------------------
>
>                 Key: JBPORTAL-990
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-990
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>
> Implement an AJAX lib to allow user positioning of windows.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:45 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-887) Portal UI
 usuability improvements
Message-ID: <12033745.1157322345396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-887?page=all ]

Roy Russo updated JBPORTAL-887:
-------------------------------

    Affects Version/s: 2.6.Alpha1
                           (was: 2.2 Branch)

> Portal UI usuability improvements
> ---------------------------------
>
>                 Key: JBPORTAL-887
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-887
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Roy Russo
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> some stuff that can be improved in UI Usuability
> 1) In Admin Portlet when you add portlet instances to a page the list of them is not sorted anyway so it's hard to fine what you want. Plus possibly with many portlets it will be hard to handle it from drop down list

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:45 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-993) UI for users
 adding windows to a page
In-Reply-To: <21966823.1156184862411.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24462326.1157322345507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-993?page=all ]

Roy Russo updated JBPORTAL-993:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI for users adding windows to a page
> -------------------------------------
>
>                 Key: JBPORTAL-993
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-993
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 20:37:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sun, 3 Sep 2006 20:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-115) NPE in ViewTopic
In-Reply-To: <1960202.1154560871633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26161268.1157330263963.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-115?page=comments#action_12342719 ] 
            
Ryszard Kozmik commented on JBFORUMS-115:
-----------------------------------------

I noticed that this exception is thrown only when accessing TopicView by external link. If you navigate normally to specified topic you won't get this exception. Moreover, this problem occurs in any topic, not just in this one.

> NPE in ViewTopic
> ----------------
>
>                 Key: JBFORUMS-115
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-115
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>
> Clicking this link http://forums.proto.jboss.com:8080/portal/index.html?ctrl:cmd=render&ctrl:window=default.default.DefaultCMSPortletWindow&t=12&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2Fviews%2Ftopics%2Fviewtopic_body.jsf , causes whole forums to dissapear and throw this exception:
> 18:06:20,855 ERROR [[/portal-forums]] Exception in FacesServlet
> java.lang.NullPointerException
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:393)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:94)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:128)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContainer.java:521)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.java:433)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInvocation.java:79)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.component.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.component.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.NavigationInterceptor.invoke(NavigationInterceptor.java:76)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.CacheInterceptor.invoke(CacheInterceptor.java:111)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ModesInterceptor.invoke(ModesInterceptor.java:88)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:87)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPostDispatchInterceptor.invoke(SessionPostDispatchInterceptor.java:65)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:129)
>         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.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:101)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
>         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>         at org.jboss.portal.server.app.impl.AbstractRequestContext.include(AbstractRequestContext.java:247)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:73)
>         at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:81)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:79)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPreDispatchInterceptor.invoke(SessionPreDispatchInterceptor.java:94)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.ValveInterceptor.invoke(ValveInterceptor.java:64)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:84)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:68)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:141)
>         at org.jboss.portal.core.command.RenderPageCommand.renderPortlets(RenderPageCommand.java:231)
>         at org.jboss.portal.core.command.RenderPageCommand.execute(RenderPageCommand.java:164)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:58)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:93)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:151)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:77)
>         at org.jboss.portal.core.CoreController.handle(CoreController.java:190)
>         at sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
>         at $Proxy136.handle(Unknown Source)
>         at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:76)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.server.SubjectAssociationInterceptor.invoke(SubjectAssociationInterceptor.java:47)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.PolicyAssociationInterceptor.invoke(PolicyAssociationInterceptor.java:52)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:69)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:184)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:87)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java:75)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:221)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 22:27:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Sun, 3 Sep 2006 22:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-298) Throws
 CurrentModificationException when start several consoles running our
 application
Message-ID: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>

Throws CurrentModificationException when start several consoles running our application
---------------------------------------------------------------------------------------

                 Key: JGRP-298
                 URL: http://jira.jboss.com/jira/browse/JGRP-298
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3
         Environment: Windows XP, JDK 5.0
            Reporter: Sammi Ting
         Assigned To: Bela Ban
            Priority: Minor


Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37

2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
....
2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
	at org.jgroups.protocols.TP.down(TP.java:673)
	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 22:29:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Sun, 3 Sep 2006 22:29:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-298) Throws
 CurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22517182.1157336983954.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Sammi Ting updated JGRP-298:
----------------------------

    Attachment: debug.log

> Throws CurrentModificationException when start several consoles running our application
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 22:37:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Sun, 3 Sep 2006 22:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-298) Throws
 ConcurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5571195.1157337463885.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Sammi Ting updated JGRP-298:
----------------------------

    Summary: Throws ConcurrentModificationException when start several consoles running our application  (was: Throws CurrentModificationException when start several consoles running our application)

> Throws ConcurrentModificationException when start several consoles running our application
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 01:13:46 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Mon, 4 Sep 2006 01:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-360) wrong spelling in
 Hibernate Code Generation window
In-Reply-To: <12128434.1157316703833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11370030.1157346827001.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-360?page=all ]

Max Andersen closed JBIDE-360.
------------------------------

    Fix Version/s: 2.0.0.Beta2
       Resolution: Done

fixed thanks

> wrong spelling in Hibernate Code Generation window
> --------------------------------------------------
>
>                 Key: JBIDE-360
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-360
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>            Priority: Trivial
>             Fix For: 2.0.0.Beta2
>
>
> wrong spelling in Hibernate Code Generation window => "Main" tab => "Dectect optimistic lock columns" checkbox.
> instead of "Dectect" it should be "Detect"

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 01:43:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 01:43:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-298) Throws
 ConcurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7804528.1157348623871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Bela Ban updated JGRP-298:
--------------------------

    Fix Version/s: 2.4
      Description: 
Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37

2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
....
2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;
send_buf_size=100000;loopback=true):TCPPING(timeout=3000;
initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):
FD(timeout=2000;max_tries=4):
VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):
pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;
max_bytes=40000000;down_thread=false;up_thread=false):
VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):
pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
	at org.jgroups.protocols.TP.down(TP.java:673)
	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

  was:
Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37

2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
....
2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
	at org.jgroups.protocols.TP.down(TP.java:673)
	at org.jgroups.stack.DownHandler.run(Protocol.java:121)


> Throws ConcurrentModificationException when start several consoles running our application
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;
> send_buf_size=100000;loopback=true):TCPPING(timeout=3000;
> initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):
> FD(timeout=2000;max_tries=4):
> VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
> pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):
> pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;
> max_bytes=40000000;down_thread=false;up_thread=false):
> VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):
> pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 02:01:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Mon, 4 Sep 2006 02:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-298) Throws
 ConcurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1198841.1157349703853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Sammi Ting closed JGRP-298.
---------------------------

    Resolution: Done

Found 2.4 should solve the problem.

> Throws ConcurrentModificationException when start several consoles running our application
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;
> send_buf_size=100000;loopback=true):TCPPING(timeout=3000;
> initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):
> FD(timeout=2000;max_tries=4):
> VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
> pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):
> pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;
> max_bytes=40000000;down_thread=false;up_thread=false):
> VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):
> pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 03:33:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 03:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-655) Refactor @Service
	beans
In-Reply-To: <30703765.1153251191416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16370014.1157355223871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-655?page=all ]

Carlo de Wolf updated EJBTHREE-655:
-----------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Refactor @Service beans
> -----------------------
>
>                 Key: EJBTHREE-655
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-655
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Refactor @Service beans to fix a number of problems:
> * magic methods for lifecycle methods:
>   - create/start/stop/destroy
> * lifecycle methods are not required to be in @Management (MBean) interface.
> * @Management interface is not registered with the ServiceController (Controller in MC land).  It *IS* registered as a regular MBean though.
> * If lifecycle methods exist on @Management interface, they must be intercepted on the container so that the appropriate Controler start/stop is done on the container.  This would mean that you have to specify a <bind> in the Service aspect domain in ejb3-interceptors-aop.xml

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 04:45:44 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 4 Sep 2006 04:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-447) correct
 NullPointer when processing PRIORITY rule tag
In-Reply-To: <21683851.1156360189213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13424503.1157359544045.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-447?page=comments#action_12342731 ] 
            
Michael Neale commented on JBRULES-447:
---------------------------------------

ah right... well priority isn't really meant to work that way, you need to set it on each rule row (you can merge cells so you only set it once). 

Still, a NPE should not be thrown, either it should apply the Priority to all, or else give an explicit failure message.

The same could be said of other rule attributes that can be set. I may apply this to TRUNK (but not to 3.0.x) - thanks !

> correct NullPointer when processing PRIORITY rule tag
> -----------------------------------------------------
>
>                 Key: JBRULES-447
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-447
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Michael Neale
>         Attachments: jboss_rules_priority.diff, PriorityTest.xls
>
>
> diff attached. I'm not sure if using LshBuilder is the correct thing to do ...

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 04:49:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 4 Sep 2006 04:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-444) patch to support
 Notes attribute on decision table Package
In-Reply-To: <9769524.1156268351914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11630007.1157359783844.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-444?page=comments#action_12342732 ] 
            
Michael Neale commented on JBRULES-444:
---------------------------------------

Thanks ! Will apply to trunk (not to 3.0.x branch).

> patch to support Notes attribute on decision table Package
> ----------------------------------------------------------
>
>                 Key: JBRULES-444
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-444
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Mark Proctor
>            Priority: Optional
>             Fix For: 3.0.4
>
>         Attachments: jboss_rules_decisiontable_package_notes.diff
>
>
> patch attached

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 05:17:48 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 4 Sep 2006 05:17:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-435) Large integer
 values in
 decision tables are converted to scientific notation in DRL which cannot be
 parsed
In-Reply-To: <8098647.1155759034300.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23611920.1157361468776.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-435?page=comments#action_12342734 ] 
            
Michael Neale commented on JBRULES-435:
---------------------------------------

hmmm... yes. A few ways to solve this.

The immediate workaround is to make it text in the spreadsheet cell, not a number, then it should come out verbatim.

Otherwise we can either 
a) make the DRL support scientific notation
b) make the XLS parser convert it to long notation form.

> Large integer values in decision tables are converted to scientific notation in DRL which cannot be parsed
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-435
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-435
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Drl Parser/Builder
>            Reporter: Volker Augustin
>         Assigned To: Michael Neale
>
> When a condition column in a decision table contains values like 25000000, this is compiled using the SpreadsheetCompiler into 2.5E7 in the DRL. However, the DRL parser/compiler cannot cope with this notation and exists with a unexpected token "E7" error 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

        


From jira-events at jboss.com  Mon Sep  4 05:29:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 05:29:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21307845.1157362183781.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-296?page=comments#action_12342735 ] 
            
Bela Ban commented on JGRP-296:
-------------------------------

The properties will be documented here: http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps

> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 05:41:44 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 05:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-667) IIOP binding
In-Reply-To: <28082874.1154072651386.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18958733.1157362904526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-667?page=all ]

Carlo de Wolf resolved EJBTHREE-667.
------------------------------------

    Resolution: Done

> IIOP binding
> ------------
>
>                 Key: EJBTHREE-667
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-667
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Make IIOP binding work in the EJB3 stack.
> To use IIOP on an EJB bean, the following code is used:
> @RemoteBinding(factory=org.jboss.ejb3.iiop.IORFactory.class)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 06:05:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 4 Sep 2006 06:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3522) Include jbossws-1.0.3
In-Reply-To: <18625778.1155717623768.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21268304.1157364343801.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3522?page=all ]

Dimitris Andreadis closed JBAS-3522.
------------------------------------

    Fix Version/s: JBossAS-4.0.5.CR1
                       (was: JBossAS-4.0.5.GA)
       Resolution: Out of Date

This update was scheduled for 4.0.5.GA, but took place in 4.0.5.CR1

> Include jbossws-1.0.3
> ---------------------
>
>                 Key: JBAS-3522
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3522
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep  4 06:09:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 06:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2854013.1157364583897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-296?page=all ]

Bela Ban updated JGRP-296:
--------------------------

    Description: 
- bind.address
- ignore.bind.address
- jboss.tcpping.initial_hosts
- jboss.partition.udpPort
- jboss.partition.udpGroup
- jboss.mcast.ip.ttl

#1 Collect all system properties used by JGroups
#2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
#3 Document all properties used by JGroups
#4 Implement support for both new and old system properties: try to get the value for the new one first (e.g. jgroups.bind_addr), then - if not found - the old one (bind.address). In this case, it probably makes sense to create a function in Util which does this, plus also takes jgroups.ignore.bind_addr into account

  was:
- bind.address
- ignore.bind.address
- jboss.tcpping.initial_hosts
- jboss.partition.udpPort
- jboss.partition.udpGroup
- jboss.mcast.ip.ttl

#1 Collect all system properties used by JGroups
#2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
#3 Document all properties used by JGroups


> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups
> #4 Implement support for both new and old system properties: try to get the value for the new one first (e.g. jgroups.bind_addr), then - if not found - the old one (bind.address). In this case, it probably makes sense to create a function in Util which does this, plus also takes jgroups.ignore.bind_addr into account

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 06:25:43 2006
From: jira-events at jboss.com (Valerij Timofeev (JIRA))
Date: Mon, 4 Sep 2006 06:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20785850.1157365543845.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=comments#action_12342739 ] 
            
Valerij Timofeev commented on JBSEAM-340:
-----------------------------------------

A seam-gen generated scaffold application  relies only on the Seam properties files, for example :

@NotNull
@Length(min = 1, max = 50, message = "#{messages['err.fullname.length']}")
    public String getFullname()
    {
        return fullname;
    }

According entry in a properties file can look so:

err.fullname.length        = Fullname is mandatory and should be maximal 50 characters long

The problem is obvious: max length information is spread among two places :-(

The following form unfortunately doesn't work

err.fullname.length        = Fullname is mandatory and should be maximal {max} characters long

I suppose this could be a feature request: Seam messages must be able to interpret hibernate-validator alike variables {max}


> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Mon Sep  4 07:07:44 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 07:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-653) No pooling for
 stateless session beans
In-Reply-To: <12321988.1153207692016.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25389221.1157368064397.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-653?page=all ]

Carlo de Wolf reassigned EJBTHREE-653:
--------------------------------------

    Assignee: Carlo de Wolf

> No pooling for stateless session beans
> --------------------------------------
>
>                 Key: EJBTHREE-653
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: OS: Windows XP SP2
> JDK 1.5.0_06_b05
> JBoss AS 4.0.4 GA
>            Reporter: Guido Bening
>         Assigned To: Carlo de Wolf
>
> Scenario:
> Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
> The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
> CallBack method:
>     /**
>      * EJBCreate method.
>      */
>     @PostConstruct
>     public void ejb3Create() {
>         System.out.println("New SessionBean " + this);
>         System.out.println("Thread " + Thread.currentThread().getId());
>         setupBean();
>     }
>     
> And the log for a few of the 1000 calls:
> ...
> 09:17:51,119 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 231ae2
> 09:17:51,129 INFO  [STDOUT] Thread 97
> 09:17:51,139 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1662174
> 09:17:51,139 INFO  [STDOUT] Thread 97
> 09:17:51,219 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 189f155
> 09:17:51,219 INFO  [STDOUT] Thread 97
> 09:17:51,239 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a82dfb
> 09:17:51,239 INFO  [STDOUT] Thread 97
> 09:17:51,289 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 198813a
> 09:17:51,289 INFO  [STDOUT] Thread 97
> 09:17:51,309 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 59eefd
> 09:17:51,309 INFO  [STDOUT] Thread 97
> 09:17:51,359 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 2e3520
> 09:17:51,369 INFO  [STDOUT] Thread 97
> 09:17:51,379 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1ed457
> 09:17:51,379 INFO  [STDOUT] Thread 97
> 09:17:51,439 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1e1c7f3
> 09:17:51,439 INFO  [STDOUT] Thread 97
> 09:17:51,449 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 15cb8ed
> 09:17:51,449 INFO  [STDOUT] Thread 97
> 09:17:51,519 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a4a949
> 09:17:51,519 INFO  [STDOUT] Thread 97
> 09:17:51,529 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19ae0a
> 09:17:51,529 INFO  [STDOUT] Thread 97
> 09:17:51,589 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 567fa0
> 09:17:51,599 INFO  [STDOUT] Thread 97
> 09:17:51,609 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19956fe
> 09:17:51,609 INFO  [STDOUT] Thread 97
> 09:17:51,659 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 150e574
> 09:17:51,669 INFO  [STDOUT] Thread 97
> 09:17:51,679 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at aa46ad
> 09:17:51,679 INFO  [STDOUT] Thread 97
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 07:37:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 07:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-653) No pooling for
 stateless session beans
In-Reply-To: <12321988.1153207692016.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28291299.1157369863907.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-653?page=comments#action_12342741 ] 
            
Carlo de Wolf commented on EJBTHREE-653:
----------------------------------------

Test in in regression/ejbthree653

> No pooling for stateless session beans
> --------------------------------------
>
>                 Key: EJBTHREE-653
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: OS: Windows XP SP2
> JDK 1.5.0_06_b05
> JBoss AS 4.0.4 GA
>            Reporter: Guido Bening
>         Assigned To: Carlo de Wolf
>
> Scenario:
> Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
> The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
> CallBack method:
>     /**
>      * EJBCreate method.
>      */
>     @PostConstruct
>     public void ejb3Create() {
>         System.out.println("New SessionBean " + this);
>         System.out.println("Thread " + Thread.currentThread().getId());
>         setupBean();
>     }
>     
> And the log for a few of the 1000 calls:
> ...
> 09:17:51,119 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 231ae2
> 09:17:51,129 INFO  [STDOUT] Thread 97
> 09:17:51,139 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1662174
> 09:17:51,139 INFO  [STDOUT] Thread 97
> 09:17:51,219 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 189f155
> 09:17:51,219 INFO  [STDOUT] Thread 97
> 09:17:51,239 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a82dfb
> 09:17:51,239 INFO  [STDOUT] Thread 97
> 09:17:51,289 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 198813a
> 09:17:51,289 INFO  [STDOUT] Thread 97
> 09:17:51,309 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 59eefd
> 09:17:51,309 INFO  [STDOUT] Thread 97
> 09:17:51,359 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 2e3520
> 09:17:51,369 INFO  [STDOUT] Thread 97
> 09:17:51,379 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1ed457
> 09:17:51,379 INFO  [STDOUT] Thread 97
> 09:17:51,439 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1e1c7f3
> 09:17:51,439 INFO  [STDOUT] Thread 97
> 09:17:51,449 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 15cb8ed
> 09:17:51,449 INFO  [STDOUT] Thread 97
> 09:17:51,519 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a4a949
> 09:17:51,519 INFO  [STDOUT] Thread 97
> 09:17:51,529 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19ae0a
> 09:17:51,529 INFO  [STDOUT] Thread 97
> 09:17:51,589 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 567fa0
> 09:17:51,599 INFO  [STDOUT] Thread 97
> 09:17:51,609 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19956fe
> 09:17:51,609 INFO  [STDOUT] Thread 97
> 09:17:51,659 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 150e574
> 09:17:51,669 INFO  [STDOUT] Thread 97
> 09:17:51,679 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at aa46ad
> 09:17:51,679 INFO  [STDOUT] Thread 97
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 08:19:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 4 Sep 2006 08:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
Message-ID: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
-------------------------------------------------------------------------------------------

                 Key: JBAS-3620
                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
             Fix For: JBossAS-4.0.5.GA


JBossMQ's PersistenceManager has a mechanism to retry recovery
a number of times "RecoveryRetries".

However, this only applies to the data recovery. If it fails 
(e.g. due to database or network glitch)
while checking/creating the database schema
then no retries are done.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 08:27:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 4 Sep 2006 08:27:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
In-Reply-To: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25617993.1157372864038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3620?page=all ]

Adrian Brock updated JBAS-3620:
-------------------------------

    Workaround Description: 
Boot JBoss once to create the tables (or create them manually)
then change the persistence manager config to:
CREATE_TABLES_ON_STARTUP = FALSE
                Workaround: [Workaround Exists]

> JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBossMQ's PersistenceManager has a mechanism to retry recovery
> a number of times "RecoveryRetries".
> However, this only applies to the data recovery. If it fails 
> (e.g. due to database or network glitch)
> while checking/creating the database schema
> then no retries are done.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 09:05:43 2006
From: jira-events at jboss.com (Heiko W. Rupp (JIRA))
Date: Mon, 4 Sep 2006 09:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3621) Possible bad
 implementation of compareOID()
Message-ID: <26398861.1157375143836.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible bad implementation of compareOID()
-------------------------------------------

                 Key: JBAS-3621
                 URL: http://jira.jboss.com/jira/browse/JBAS-3621
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Heiko W. Rupp
         Assigned To: Heiko W. Rupp




-- 
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

        


From jira-events at jboss.com  Mon Sep  4 09:27:43 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 4 Sep 2006 09:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-77) wrong parent object for
 nested model groups
In-Reply-To: <13844019.1154942652342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10597969.1157376463879.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-77?page=all ]

Alexey Loubyansky closed JBXB-77.
---------------------------------

    Resolution: Done

Fixed.

> wrong parent object for nested model groups
> -------------------------------------------
>
>                 Key: JBXB-77
>                 URL: http://jira.jboss.com/jira/browse/JBXB-77
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0
>
>
> In the current impl If the model group binding is used then the parent object for a model group on the stack that will be the object created for the last element on the stack. Even if the parent of the model group is another model group.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:25:43 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 4 Sep 2006 10:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-81) DTDMarshaller:
 redundant
 startElement call for complex elements with character content
Message-ID: <4958400.1157379943792.JavaMail.jira@cloud.prod.atl2.jboss.com>

DTDMarshaller: redundant startElement call for complex elements with character content
--------------------------------------------------------------------------------------

                 Key: JBXB-81
                 URL: http://jira.jboss.com/jira/browse/JBXB-81
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-1.0.0.CR6
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky
             Fix For: JBossXB-1.0


Characters content of an element with mixed content will appear in a child element with the same name as the element being marshalled.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:27:46 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 10:27:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-292) Deadlock
In-Reply-To: <556149.1157029098201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10616007.1157380066885.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-292?page=comments#action_12342747 ] 
            
Bela Ban commented on JGRP-292:
-------------------------------

The deadlock was fixed by
- converting synchronized(mutex) into a EDU.util.concurrent.CondVar and ReentrantLock
- releasing the lock while sending the credit request and re-acquiring it afterwards

The code in FC looks a bit ugly, but with JDK 5's util.concurrent.lock.ReentrantLock/Condition, the lock() and unlock() methods will not have to be guarded by a try-catch clause (uninterruptible).

> Deadlock
> --------
>
>                 Key: JGRP-292
>                 URL: http://jira.jboss.com/jira/browse/JGRP-292
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Critical
>             Fix For: 2.4
>
>
> Stack dump shows deadlock:
> Name: http-192.168.5.2-8180-5
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 35,522  Total waited: 401
> Stack trace: 
> java.lang.Object.wait(Native Method)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:360)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: http-192.168.5.2-8180-4
> State: BLOCKED on org.jgroups.protocols.UNICAST$Entry at 13e6987 owned by: IncomingPacketHandler (channel=Tomcat-Cluster)
> Total blocked: 39,178  Total waited: 490
> Stack trace: 
> org.jgroups.protocols.UNICAST.down(UNICAST.java:264)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:283)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.GMS.down(GMS.java:809)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FC.sendCreditRequest(FC.java:528)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:365)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: IncomingPacketHandler (channel=Tomcat-Cluster)
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 85,549  Total waited: 18,813
> Stack trace: 
> org.jgroups.protocols.FC.handleCredit(FC.java:462)
> org.jgroups.protocols.FC.up(FC.java:319)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.GMS.up(GMS.java:753)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:773)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:471)
> org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:185)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD.up(FD.java:274)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:303)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.Discovery.up(Discovery.java:225)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.TP.handleIncomingMessage(TP.java:918)
> org.jgroups.protocols.TP.handleIncomingPacket(TP.java:860)
> org.jgroups.protocols.TP.access$200(TP.java:45)
> org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1294)
> java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:27:46 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 4 Sep 2006 10:27:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-81) DTDMarshaller: redundant
 startElement call for complex elements with character content
In-Reply-To: <4958400.1157379943792.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5742847.1157380067000.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-81?page=all ]

Alexey Loubyansky closed JBXB-81.
---------------------------------

    Resolution: Done

Fixed.

> DTDMarshaller: redundant startElement call for complex elements with character content
> --------------------------------------------------------------------------------------
>
>                 Key: JBXB-81
>                 URL: http://jira.jboss.com/jira/browse/JBXB-81
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0
>
>
> Characters content of an element with mixed content will appear in a child element with the same name as the element being marshalled.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:27:47 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 10:27:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-292) Deadlock
In-Reply-To: <556149.1157029098201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24657521.1157380067135.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-292?page=all ]

Bela Ban resolved JGRP-292.
---------------------------

    Resolution: Done

Tested on both local laptop and ATL cluster lab, with 80M messages, no deadlocks

> Deadlock
> --------
>
>                 Key: JGRP-292
>                 URL: http://jira.jboss.com/jira/browse/JGRP-292
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Critical
>             Fix For: 2.4
>
>
> Stack dump shows deadlock:
> Name: http-192.168.5.2-8180-5
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 35,522  Total waited: 401
> Stack trace: 
> java.lang.Object.wait(Native Method)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:360)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: http-192.168.5.2-8180-4
> State: BLOCKED on org.jgroups.protocols.UNICAST$Entry at 13e6987 owned by: IncomingPacketHandler (channel=Tomcat-Cluster)
> Total blocked: 39,178  Total waited: 490
> Stack trace: 
> org.jgroups.protocols.UNICAST.down(UNICAST.java:264)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:283)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.GMS.down(GMS.java:809)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FC.sendCreditRequest(FC.java:528)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:365)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: IncomingPacketHandler (channel=Tomcat-Cluster)
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 85,549  Total waited: 18,813
> Stack trace: 
> org.jgroups.protocols.FC.handleCredit(FC.java:462)
> org.jgroups.protocols.FC.up(FC.java:319)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.GMS.up(GMS.java:753)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:773)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:471)
> org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:185)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD.up(FD.java:274)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:303)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.Discovery.up(Discovery.java:225)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.TP.handleIncomingMessage(TP.java:918)
> org.jgroups.protocols.TP.handleIncomingPacket(TP.java:860)
> org.jgroups.protocols.TP.access$200(TP.java:45)
> org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1294)
> java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 11:11:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Mon, 4 Sep 2006 11:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-759) Create a set of
 deadlock-detecting unit tests
Message-ID: <24324626.1157382703762.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a set of deadlock-detecting unit tests
---------------------------------------------

                 Key: JBCACHE-759
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-759
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.0


>From email thread:

"Okay, found out that jconsole also supports it:
MBeans --> java.lang --> Threading --> Operations --> findMonitorDeadlockedThreads().

Of course, if we could integrate this into our test suites to regularly check for deadlocks..."

Article from JavaSpecialists:

    http://www.javaspecialists.co.za/archive/newsletter.do?issue=130&locale=en_US

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 11:41:47 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Mon, 4 Sep 2006 11:41:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-105) Make this JSF
 based system work on JBoss Portal 2.4
In-Reply-To: <7238225.1153926131402.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27784904.1157384507036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-105?page=all ]

Ryszard Kozmik reassigned JBFORUMS-105:
---------------------------------------

    Assignee: Ryszard Kozmik  (was: Sohil Shah)

> Make this JSF based system work on JBoss Portal 2.4
> ---------------------------------------------------
>
>                 Key: JBFORUMS-105
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-105
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>
> Investigate what need to be done to make this work on JBoss Portal 2.4
> Currently supported Portal version = 2.2.1RC1

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 12:01:43 2006
From: jira-events at jboss.com (bugra uytun (JIRA))
Date: Mon, 4 Sep 2006 12:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
In-Reply-To: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21309197.1157385703947.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-359?page=comments#action_12342753 ] 
            
bugra uytun commented on JBIDE-359:
-----------------------------------

After reading your comment I noticed that I wasn't precise enough and left room for misunderstanding, so I would like to explain it in more detail.

My DB (Apache Derby 10.1) uses as default schema "APP" but the tables I need are in "mySchema" schema where also the table "MY_TABLE" resides. To get the correct schema and the tables I needed to define the "hibernate.default_schema" property in .cfg.xml file - this doesn't mean that this must be the same default schema in my DB. But since the reverse engineered automagically generated .hbm.xml files do not contain the "schema" attribute hibernate tries to find the tables in the default schema - in this case in "APP" but this schema does not have such a table.

To get the correct table from correct schema I have to add the "schema" attribute to all generated .hbm.xml files by hand or I have to set he default schema on my DB to what I need - in this case to "mySchema".

I hope that I could clarify my position and I would appreciate if you reconsider this bug/whish list/etc. In case that I'm missing an already existing feature/checkbox/etc. I would be happy to use this and sorry for the annoyance.


> hibernate reverse engineering does not set "schema" attribute in .hbm.xml
> -------------------------------------------------------------------------
>
>                 Key: JBIDE-359
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>
> i set the schema in hibernate.cfg.xml with:
> ---
> <property name="hibernate.default_schema">mySchema</property>
> ---
> after reverse engineering the DB I get the .hbm.xml file
> ---
> ...
> <hibernate-mapping>
>     <class name="com.someclass" table="MY_TABLE">
> ...
> ---
> notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:
> ---
> org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
> ---

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 12:13:43 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Mon, 4 Sep 2006 12:13:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
In-Reply-To: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30165276.1157386423845.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-359?page=comments#action_12342755 ] 
            
Max Andersen commented on JBIDE-359:
------------------------------------

you should use the tools forum for these things in the future before reporting features as bugs ;)

look at <schema-selection> and if that doesn't help ask on forum.hibernate.org

> hibernate reverse engineering does not set "schema" attribute in .hbm.xml
> -------------------------------------------------------------------------
>
>                 Key: JBIDE-359
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>
> i set the schema in hibernate.cfg.xml with:
> ---
> <property name="hibernate.default_schema">mySchema</property>
> ---
> after reverse engineering the DB I get the .hbm.xml file
> ---
> ...
> <hibernate-mapping>
>     <class name="com.someclass" table="MY_TABLE">
> ...
> ---
> notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:
> ---
> org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
> ---

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 13:27:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 13:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-666) Throw
 javax.ejb.ConcurrentAccessException when two threads access the same SFSB
 instance
In-Reply-To: <29278907.1153950371470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32785197.1157390863980.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-666?page=all ]

Carlo de Wolf reassigned EJBTHREE-666:
--------------------------------------

    Assignee: Carlo de Wolf

> Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-666
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> See section 4.13.3 of the EJB Core Contracts specification.
> I need this for Seam.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:45:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-680) Standard
 security domain for ejb3 deployments
In-Reply-To: <6594371.1154619131314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15735216.1157409944628.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-680?page=comments#action_12342776 ] 
            
William DeCoste commented on EJBTHREE-680:
------------------------------------------

EJB RC9 now supports use of the Properties Service for deployment descriptors - this provides this requested functionality.

> Standard security domain for ejb3 deployments
> ---------------------------------------------
>
>                 Key: EJBTHREE-680
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-680
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>
> The ejb3 container could provide an optional standard security domain that is used when a bean doesn't provide a SecurityDomain annotation. The ejb 2.x stack provides this feature already (in standarjboss.xml). 
> This feature is important in environments in which the same deployment is deployed into different JBoss servers (e.g a test JBoss instance may have another default security domain than production). 

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:45:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-680) Standard security
 domain for ejb3 deployments
In-Reply-To: <6594371.1154619131314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14298304.1157409944810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-680?page=all ]

William DeCoste closed EJBTHREE-680.
------------------------------------

    Resolution: Done

> Standard security domain for ejb3 deployments
> ---------------------------------------------
>
>                 Key: EJBTHREE-680
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-680
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>
> The ejb3 container could provide an optional standard security domain that is used when a bean doesn't provide a SecurityDomain annotation. The ejb 2.x stack provides this feature already (in standarjboss.xml). 
> This feature is important in environments in which the same deployment is deployed into different JBoss servers (e.g a test JBoss instance may have another default security domain than production). 

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:49:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25007887.1157410183945.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=comments#action_12342777 ] 
            
William DeCoste commented on EJBTHREE-679:
------------------------------------------

EJB RC9 now supports use of the Properties Service for deployment descriptors - this provides this requested functionality. 

> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:49:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:49:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28911184.1157410184135.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=all ]

William DeCoste closed EJBTHREE-679.
------------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD
       Resolution: Done

> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:57:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Mon, 4 Sep 2006 18:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1018) Do not display
 edit mode when user is not logged in
Message-ID: <1888465.1157410663830.JavaMail.jira@cloud.prod.atl2.jboss.com>

Do not display edit mode when user is not logged in
---------------------------------------------------

                 Key: JBPORTAL-1018
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1018
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep  4 19:25:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 19:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-628) Redeployment
 doesn't work with E-EJB3
Message-ID: <23868561.1157412344792.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-628?page=all ]

William DeCoste closed EJBTHREE-628.
------------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD
       Resolution: Done

> Redeployment doesn't work with E-EJB3
> -------------------------------------
>
>                 Key: EJBTHREE-628
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-628
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Christian Bauer
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I'm executing the following sequence:
> EJB3StandaloneBootstrap.boot(null);
> EJB3StandaloneBootstrap.deployXmlResource("META-INF/jboss-beans.xml");
> EJB3StandaloneDeployer deployer =  EJB3StandaloneBootstrap.createDeployer();
> deployer.getArchivesByResource().add("META-INF/persistence.xml");
> deployer.create();
> deployer.start();
> deployer.stop();
> deployer.destroy();
> deployer.create();
> deployer.start();
> This fails on the second start() with this:
> 12:34:17,397  INFO MCKernelAbstraction:84 - installing bean:  jboss.j2ee:jar=classes,name=PlaceItemBean,service=EJB3 with  dependencies:
> 12:34:17,399  INFO MCKernelAbstraction:87 -      AbstractDependencyMetaData at 44fc5e {dependency=persistence.units:jar=classes.jar,unitName=caveatemptorDatab ase}
> 12:34:17,688 ERROR AbstractKernelController:350 - Error installing to  Start: name=jboss.j2ee:jar=classes,name=PlaceItemBean,service=EJB3  state=Create
> javax.naming.NamingException: Could not bind user transaction for ejb  name PlaceItemBean into JNDI under jndiName: /UserTransaction [Root  exception is javax.naming.NameAlreadyBoundException]
>     at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:650)
>     at org.jboss.ejb3.EJBContainer.initializePool(EJBContainer.java:595)
>     at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:526)
>     at org.jboss.ejb3.SessionContainer.start(SessionContainer.java:82)
>     at org.jboss.ejb3.stateful.StatefulContainer.start (StatefulContainer.java:73)
>     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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke (ReflectionUtils.java:55)
>     at  org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke (ReflectMethodInfoImpl.java:107)
>     at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch (BasicMethodJoinPoint.java:66)
>     at  org.jboss.kernel.plugins.dependency.KernelControllerContextActions.dispa tchJoinPoint(KernelControllerContextActions.java:100)
>     at org.jboss.kernel.plugins.dependency.KernelControllerContextActions $LifecycleAction.installAction(KernelControllerContextActions.java:582)
>     at org.jboss.kernel.plugins.dependency.KernelControllerContextActions $KernelControllerContextAction.install (KernelControllerContextActions.java:175)
>     at  org.jboss.dependency.plugins.AbstractControllerContextActions.install (AbstractControllerContextActions.java:51)
>     at org.jboss.dependency.plugins.AbstractControllerContext.install (AbstractControllerContext.java:226)
>     at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:593)
>     at org.jboss.dependency.plugins.AbstractController.incrementState (AbstractController.java:346)
>     at org.jboss.dependency.plugins.AbstractController.resolveContexts (AbstractController.java:438)
>     at org.jboss.dependency.plugins.AbstractController.resolveContexts (AbstractController.java:379)
>     at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:225)
>     at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:151)
>     at  org.jboss.kernel.plugins.dependency.AbstractKernelController.install (AbstractKernelController.java:79)
>     at  org.jboss.kernel.plugins.dependency.AbstractKernelController.install (AbstractKernelController.java:73)
>     at org.jboss.ejb3.MCKernelAbstraction.install (MCKernelAbstraction.java:91)
>     at org.jboss.ejb3.Ejb3Deployment.registerEJBContainer (Ejb3Deployment.java:439)
>     at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:486)
>     at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.start (EJB3StandaloneDeployer.java:460)
>     at org.hibernate.ce.auction.test.runtime.IntegrationTest.cleanup (IntegrationTest.java:73)
>     at org.hibernate.ce.auction.test.foo.TestOne.afterTest(TestOne.java:18)
>     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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:552)
>     at org.testng.internal.Invoker.invokeConfigurationMethod (Invoker.java:318)
>     at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:152)
>     at org.testng.internal.Invoker.invokeMethod(Invoker.java:483)
>     at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:778)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:105)
>     at org.testng.TestRunner.privateRun(TestRunner.java:682)
>     at org.testng.TestRunner.run(TestRunner.java:566)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:220)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:146)
>     at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:86)
>     at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:123)
> Caused by: javax.naming.NameAlreadyBoundException
>     at org.jnp.server.NamingServer.bind(NamingServer.java:144)
>     at org.jnp.interfaces.NamingContext.bind(NamingContext.java:567)
>     at org.jnp.interfaces.NamingContext.bind(NamingContext.java:532)
>     at org.jboss.util.naming.Util.bind(Util.java:102)
>     at org.jboss.util.naming.Util.bind(Util.java:89)
>     at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:647)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 19:51:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Mon, 4 Sep 2006 19:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1018) Do not display
 edit mode when user is not logged in
In-Reply-To: <1888465.1157410663830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30014417.1157413903832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1018?page=all ]

Julien Viet resolved JBPORTAL-1018.
-----------------------------------

    Resolution: Done

> Do not display edit mode when user is not logged in
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1018
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1018
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From c9 at fullmailmarket.com  Tue Sep  5 00:10:45 2006
From: c9 at fullmailmarket.com (179.cl)
Date: Tue, 5 Sep 2006 00:10:45 -0400
Subject: [jboss-jira] DEFINTIVAMENTE LOS MEJORES PRECIOS PARA LLAMAR A CHILE
	Y AL EXTRANJERO :: CARRIER 179 :: OFERTA LANZAMIENTO
Message-ID: <200609050410.k854Aj8i012295@chief.dmz.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060905/76851988/attachment.html 

From jira-events at jboss.com  Tue Sep  5 01:15:26 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Tue, 5 Sep 2006 01:15:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
Message-ID: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>

CLONE -Seam and Myfaces ajax support.
-------------------------------------

                 Key: JBSEAM-342
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
             Project: JBoss Seam
          Issue Type: Feature Request
         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
            Reporter: Sergei Rogovskiy


Hi,

I have tried to use seam and myfaces sandbox component InputSugestAjax.
 Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
Please verify this issue, Maibe in the feature will be a problem in integration.

Thanks,
Cristi

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 01:21:37 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Tue, 5 Sep 2006 01:21:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15873217.1157433697862.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12342793 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

I think there is an issue with SeamVariableResolver when AJAX bean tries to resolve variable at some point. In fact using standard variable resolver solves the problem.  I am getting a nullpointer which is pretty obviosly comes from Seam. Using standard variable resolver is not a workaround since it disables all seam features, so I think the issue is pretty big.

00:14:04,033 ERROR [MyFacesResourceLoader] Could not find the class for component org.apache.myfaces.custom.templates to load a resource.
00:14:05,861 ERROR [PhaseListenerManager] Exception in PhaseListener APPLY_REQUEST_VALUES(2) beforePhase.
javax.faces.el.EvaluationException: Exception while invoking expression #{cityAjaxBean.getItems}
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:165)
        at org.apache.myfaces.custom.suggestajax.SuggestAjaxRenderer.getSuggestedItems(SuggestAjaxRenderer.java:56)
        at org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjaxRenderer.encodeAjax(InputSuggestAjaxRenderer.java:149)
        at org.apache.myfaces.custom.suggestajax.SuggestAjax.encodeAjax(SuggestAjax.java:91)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.encodeAjax(AjaxDecodePhaseListener.java:210)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.handleAjaxRequest(AjaxDecodePhaseListener.java:121)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.beforePhase(AjaxDecodePhaseListener.java:99)
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
        at org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(LifecycleImpl.java:206)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
        at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.NullPointerException
        at org.jboss.seam.contexts.PageContext.getCurrentReadableMap(PageContext.java:62)
        at org.jboss.seam.contexts.PageContext.get(PageContext.java:52)
        at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:125)
        at org.jboss.seam.Component.getInstance(Component.java:1245)
        at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
        at org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.resolveVariable(RedirectTrackerVariableResolver.java:38)
        at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
        at org.apache.myfaces.el.ValueBindingImpl$ELVariableResolver.resolveVariable(ValueBindingImpl.java:567)
        at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124)
        at org.apache.myfaces.el.ValueBindingImpl.resolveToBaseAndProperty(ValueBindingImpl.java:455)
        at org.apache.myfaces.el.MethodBindingImpl.resolveToBaseAndProperty(MethodBindingImpl.java:180)
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:114)
        ... 31 more
00:14:06,157 ERROR [PhaseListenerManager] Exception in PhaseListener APPLY_REQUEST_VALUES(2) beforePhase.
javax.faces.el.EvaluationException: Exception while invoking expression #{cityAjaxBean.getItems}
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:165)
        at org.apache.myfaces.custom.suggestajax.SuggestAjaxRenderer.getSuggestedItems(SuggestAjaxRenderer.java:56)
        at org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjaxRenderer.encodeAjax(InputSuggestAjaxRenderer.java:149)
        at org.apache.myfaces.custom.suggestajax.SuggestAjax.encodeAjax(SuggestAjax.java:91)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.encodeAjax(AjaxDecodePhaseListener.java:210)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.handleAjaxRequest(AjaxDecodePhaseListener.java:121)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.beforePhase(AjaxDecodePhaseListener.java:99)
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
        at org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(LifecycleImpl.java:206)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
        at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.NullPointerException
        at org.jboss.seam.contexts.PageContext.getCurrentReadableMap(PageContext.java:62)
        at org.jboss.seam.contexts.PageContext.get(PageContext.java:52)
        at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:125)
        at org.jboss.seam.Component.getInstance(Component.java:1245)
        at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
        at org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.resolveVariable(RedirectTrackerVariableResolver.java:38)
        at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
        at org.apache.myfaces.el.ValueBindingImpl$ELVariableResolver.resolveVariable(ValueBindingImpl.java:567)
        at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124)
        at org.apache.myfaces.el.ValueBindingImpl.resolveToBaseAndProperty(ValueBindingImpl.java:455)
        at org.apache.myfaces.el.MethodBindingImpl.resolveToBaseAndProperty(MethodBindingImpl.java:180)
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:114)
        ... 31 more

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 01:21:37 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Tue, 5 Sep 2006 01:21:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10240756.1157433698004.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12342794 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

The same thing described here: http://mail-archives.apache.org/mod_mbox/myfaces-users/200603.mbox/%3Cdvrahn$a20$1 at sea.gmane.org%3E

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 05:52:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 5 Sep 2006 05:52:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3463) Loading of
 persisted XMBean attributes does not work for custom types
In-Reply-To: <10889960.1154635811842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10065977.1157449953808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3463?page=all ]

Dimitris Andreadis reassigned JBAS-3463:
----------------------------------------

    Assignee: Dimitris Andreadis

> Loading of persisted XMBean attributes does not work for custom types
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3463
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3463
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> When using XMBean persistence for a complex attribute (my own type), all seems to go well when changes are persisted/serialized, but when the XMBean is redeployed (and its persisted state is read), there are problems unserializing the serialized data
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar -> C:\Java\jboss-4.0.4\server\test\tmp\deploy\tmp7332examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.SARDeployer at 153c375
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] about to copy 0 local directories
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, create step: url file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Registering service UCL=jmx.loading:UCL=46fef3
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.ServiceCreator] About to create xmbean object: example:service=ExampleService with code: example.ExampleService with embedded descriptor
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Loaded persistence mgr: org.jboss.mx.persistence.DelegatingPersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] init() --- ModelMBeanInfo Descriptor ---
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] descriptorType=mbean, displayName=org.jboss.mx.modelmbean.XMBean, log=F, name=org.jboss.mx.modelmbean.XMBean, objectname=(example:service=ExampleService), persistence-manager=org.jboss.mx.persistence.DelegatingPersistenceManager, persistPolicy=OnUpdate, resourceClass=example.ExampleService, visibility=1
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] chosen persistent id: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] using AttributePersistenceManager: org.jboss.system.pm.XMLAttributePersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] load() called for: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.pm.XMLAttributePersistenceManager] load(example:service=ExampleService)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.system.pm.XMLAttributePersistenceManager] Cannot deserialize object
> java.lang.ClassNotFoundException: example.ComplexAttribute
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584)
>     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
>     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
>     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
>     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.decodeFromHexString(XMLAttributePersistenceManager.java:738)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:440)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.persistence.DelegatingPersistenceManager] Caught exception while loading
> java.lang.Exception: Failed to deserialize attribute 'SomeAttribute'
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:443)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.server.registry.BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='example:service=ExampleService', Class=example.ExampleService (example.ExampleService at ae8af4)]
> 2006-08-01 14:33:59,329 INFO  [example.ExampleService] Registration is not done -> stop
> .

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 06:44:29 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 5 Sep 2006 06:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
Message-ID: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>

TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
--------------------------------------------------------------------------

                 Key: JBCACHE-760
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
    Affects Versions: 1.4.0.SP1
            Reporter: Nitzan Niv
         Assigned To: Manik Surtani


In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.

java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
	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:324)
	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)

To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:

   public void testNodeCreatedAndModifiedMapEvent() throws Exception {
       EventLog el = new EventLog(cache);
       cache.addTreeCacheListener(el);
       Map data = new HashMap();
       data.put("key", "value");
       cache.putObject("/hello/world", data);
       ...
  }

 and the relevant listener code:

      public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
         events.add("modify "+
                 (pre? "about to modify " : "Modified ") +
                 (isLocal? "local " : "remote ") + fqn);
		 if(this.cache != null && !pre) {
			try {
				cache.getObject(fqn);
			}
			catch (Exception e) {
				events.add(e);
                e.printStackTrace(System.err);
			}
		 }
      }


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 07:44:24 2006
From: jira-events at jboss.com (Doug Palmer (JIRA))
Date: Tue, 5 Sep 2006 07:44:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJMX-100) Class loader doesn't
 contain classes from MBean jar file when the MBean is redeployed.
Message-ID: <8749254.1157456665009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Class loader doesn't contain classes from MBean jar file when the MBean is redeployed.
--------------------------------------------------------------------------------------

                 Key: JBJMX-100
                 URL: http://jira.jboss.com/jira/browse/JBJMX-100
             Project: JBoss JMX
          Issue Type: Bug
    Affects Versions: JBossAS-4.0.0
         Environment: Mac OSX and Windows XP
            Reporter: Doug Palmer


This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".

To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".

If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 07:46:25 2006
From: jira-events at jboss.com (Doug Palmer (JIRA))
Date: Tue, 5 Sep 2006 07:46:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJMX-100) Class loader doesn't
 contain classes from MBean jar file when the MBean is redeployed.
In-Reply-To: <8749254.1157456665009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30824154.1157456785109.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBJMX-100?page=all ]

Doug Palmer updated JBJMX-100:
------------------------------

    Attachment: RedeployBug.zip

jboss.home and jboss.profile should be changed to reflect your jboss installation.

> Class loader doesn't contain classes from MBean jar file when the MBean is redeployed.
> --------------------------------------------------------------------------------------
>
>                 Key: JBJMX-100
>                 URL: http://jira.jboss.com/jira/browse/JBJMX-100
>             Project: JBoss JMX
>          Issue Type: Bug
>    Affects Versions: JBossAS-4.0.0
>         Environment: Mac OSX and Windows XP
>            Reporter: Doug Palmer
>         Attachments: RedeployBug.zip
>
>
> This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".
> To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".
> If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 07:50:24 2006
From: jira-events at jboss.com (Doug Palmer (JIRA))
Date: Tue, 5 Sep 2006 07:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJMX-100) Class loader doesn't
 contain classes from MBean jar file when the MBean is redeployed.
In-Reply-To: <8749254.1157456665009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9271769.1157457024329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBJMX-100?page=all ]

Doug Palmer updated JBJMX-100:
------------------------------

    Description: 
This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".  Oddly, a properties file from the package is located successfully before the class loader fails.

To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".

If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

  was:
This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".

To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".

If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.


> Class loader doesn't contain classes from MBean jar file when the MBean is redeployed.
> --------------------------------------------------------------------------------------
>
>                 Key: JBJMX-100
>                 URL: http://jira.jboss.com/jira/browse/JBJMX-100
>             Project: JBoss JMX
>          Issue Type: Bug
>    Affects Versions: JBossAS-4.0.0
>         Environment: Mac OSX and Windows XP
>            Reporter: Doug Palmer
>         Attachments: RedeployBug.zip
>
>
> This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".  Oddly, a properties file from the package is located successfully before the class loader fails.
> To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".
> If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:02:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-473) RuleItem: need to
 have URI+content not LHS/RHS
Message-ID: <26846113.1157457745377.JavaMail.jira@cloud.prod.atl2.jboss.com>

RuleItem: need to have URI+content not LHS/RHS
----------------------------------------------

                 Key: JBRULES-473
                 URL: http://jira.jboss.com/jira/browse/JBRULES-473
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:02:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-473) RuleItem: need
 to have URI+content not LHS/RHS
In-Reply-To: <26846113.1157457745377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22512229.1157457745506.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-473?page=comments#action_12342802 ] 
            
Michael Neale commented on JBRULES-473:
---------------------------------------

Will be able to store normalised stuff when parsing out (so will need some extra fields in future for searching).

> RuleItem: need to have URI+content not LHS/RHS
> ----------------------------------------------
>
>                 Key: JBRULES-473
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-473
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:02:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-420) rule storage:
	more normalised
In-Reply-To: <9873733.1155586697372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16743775.1157457745652.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-420?page=all ]

Michael Neale resolved JBRULES-420.
-----------------------------------

    Resolution: Done

> rule storage: more normalised
> -----------------------------
>
>                 Key: JBRULES-420
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-420
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> At the moment, its just a blob.
> But I think it should be:
> name
> attribute map
> LHS
> RHS
> meta-data (perhaps seperate node - dublin core stuff).

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:04:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:04:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-474) RulePackage to
 have RuleItem as child
Message-ID: <24868883.1157457865012.JavaMail.jira@cloud.prod.atl2.jboss.com>

RulePackage to have RuleItem as child
-------------------------------------

                 Key: JBRULES-474
                 URL: http://jira.jboss.com/jira/browse/JBRULES-474
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:04:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:04:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-465) scalability test
In-Reply-To: <3411872.1156952866490.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32068711.1157457865160.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-465?page=all ]

Michael Neale resolved JBRULES-465.
-----------------------------------

    Resolution: Done

> scalability test
> ----------------
>
>                 Key: JBRULES-465
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-465
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> Need to sumulate:
> 5000 rules
> 5 X 5 X 5 categories (rules spread evenly)
> 10 packages (rules spread evenly)
> To time: retrieval for a category
> retrieval for a package
> time to update a rule
> time to retrieve a rule

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:06:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:06:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-462) Package Update
	feature
In-Reply-To: <27828061.1156925503892.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12441466.1157457985996.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-462?page=comments#action_12342803 ] 
            
Michael Neale commented on JBRULES-462:
---------------------------------------

this can perhaps be done better, as the package just has a reference to a rule, and we 
"query" out the rules based on the status on request. (by default always looking at HEAD?)

> Package Update feature
> ----------------------
>
>                 Key: JBRULES-462
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-462
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> as packages have references to rules, when a rule is changed/updated, need to have a method to update packages to use the appropriate version of the rule.
> I would expect that most of the time, a package will only want to be updated when a rule status is changed to "production" for instance.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:08:25 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Tue, 5 Sep 2006 08:08:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-653) No pooling for
 stateless session beans
In-Reply-To: <12321988.1153207692016.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22611851.1157458105786.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-653?page=all ]

Carlo de Wolf resolved EJBTHREE-653.
------------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD
       Resolution: Cannot Reproduce Bug

> No pooling for stateless session beans
> --------------------------------------
>
>                 Key: EJBTHREE-653
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: OS: Windows XP SP2
> JDK 1.5.0_06_b05
> JBoss AS 4.0.4 GA
>            Reporter: Guido Bening
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Scenario:
> Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
> The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
> CallBack method:
>     /**
>      * EJBCreate method.
>      */
>     @PostConstruct
>     public void ejb3Create() {
>         System.out.println("New SessionBean " + this);
>         System.out.println("Thread " + Thread.currentThread().getId());
>         setupBean();
>     }
>     
> And the log for a few of the 1000 calls:
> ...
> 09:17:51,119 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 231ae2
> 09:17:51,129 INFO  [STDOUT] Thread 97
> 09:17:51,139 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1662174
> 09:17:51,139 INFO  [STDOUT] Thread 97
> 09:17:51,219 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 189f155
> 09:17:51,219 INFO  [STDOUT] Thread 97
> 09:17:51,239 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a82dfb
> 09:17:51,239 INFO  [STDOUT] Thread 97
> 09:17:51,289 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 198813a
> 09:17:51,289 INFO  [STDOUT] Thread 97
> 09:17:51,309 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 59eefd
> 09:17:51,309 INFO  [STDOUT] Thread 97
> 09:17:51,359 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 2e3520
> 09:17:51,369 INFO  [STDOUT] Thread 97
> 09:17:51,379 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1ed457
> 09:17:51,379 INFO  [STDOUT] Thread 97
> 09:17:51,439 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1e1c7f3
> 09:17:51,439 INFO  [STDOUT] Thread 97
> 09:17:51,449 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 15cb8ed
> 09:17:51,449 INFO  [STDOUT] Thread 97
> 09:17:51,519 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a4a949
> 09:17:51,519 INFO  [STDOUT] Thread 97
> 09:17:51,529 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19ae0a
> 09:17:51,529 INFO  [STDOUT] Thread 97
> 09:17:51,589 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 567fa0
> 09:17:51,599 INFO  [STDOUT] Thread 97
> 09:17:51,609 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19956fe
> 09:17:51,609 INFO  [STDOUT] Thread 97
> 09:17:51,659 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 150e574
> 09:17:51,669 INFO  [STDOUT] Thread 97
> 09:17:51,679 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at aa46ad
> 09:17:51,679 INFO  [STDOUT] Thread 97
> ...

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:12:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 5 Sep 2006 08:12:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3463) Loading of persisted
 XMBean attributes does not work for custom types
In-Reply-To: <10889960.1154635811842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26509391.1157458354345.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3463?page=all ]

Dimitris Andreadis updated JBAS-3463:
-------------------------------------

        Fix Version/s: JBossAS-5.0.0.Beta
                       JBossAS-3.2.8.SP2
    Affects Version/s: JBossAS-3.2.8.SP1

> Loading of persisted XMBean attributes does not work for custom types
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3463
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3463
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> When using XMBean persistence for a complex attribute (my own type), all seems to go well when changes are persisted/serialized, but when the XMBean is redeployed (and its persisted state is read), there are problems unserializing the serialized data
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar -> C:\Java\jboss-4.0.4\server\test\tmp\deploy\tmp7332examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.SARDeployer at 153c375
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] about to copy 0 local directories
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, create step: url file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Registering service UCL=jmx.loading:UCL=46fef3
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.ServiceCreator] About to create xmbean object: example:service=ExampleService with code: example.ExampleService with embedded descriptor
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Loaded persistence mgr: org.jboss.mx.persistence.DelegatingPersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] init() --- ModelMBeanInfo Descriptor ---
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] descriptorType=mbean, displayName=org.jboss.mx.modelmbean.XMBean, log=F, name=org.jboss.mx.modelmbean.XMBean, objectname=(example:service=ExampleService), persistence-manager=org.jboss.mx.persistence.DelegatingPersistenceManager, persistPolicy=OnUpdate, resourceClass=example.ExampleService, visibility=1
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] chosen persistent id: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] using AttributePersistenceManager: org.jboss.system.pm.XMLAttributePersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] load() called for: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.pm.XMLAttributePersistenceManager] load(example:service=ExampleService)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.system.pm.XMLAttributePersistenceManager] Cannot deserialize object
> java.lang.ClassNotFoundException: example.ComplexAttribute
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584)
>     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
>     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
>     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
>     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.decodeFromHexString(XMLAttributePersistenceManager.java:738)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:440)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.persistence.DelegatingPersistenceManager] Caught exception while loading
> java.lang.Exception: Failed to deserialize attribute 'SomeAttribute'
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:443)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.server.registry.BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='example:service=ExampleService', Class=example.ExampleService (example.ExampleService at ae8af4)]
> 2006-08-01 14:33:59,329 INFO  [example.ExampleService] Registration is not done -> stop
> .

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:12:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 5 Sep 2006 08:12:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3463) Loading of persisted
 XMBean attributes does not work for custom types
In-Reply-To: <10889960.1154635811842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28752093.1157458354702.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3463?page=all ]

Dimitris Andreadis closed JBAS-3463.
------------------------------------

    Resolution: Done

Should be fixed now, see
org.jboss.test.jmx.test.XMLAttributePersistenceManagerUnitTestCase

> Loading of persisted XMBean attributes does not work for custom types
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3463
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3463
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>
> When using XMBean persistence for a complex attribute (my own type), all seems to go well when changes are persisted/serialized, but when the XMBean is redeployed (and its persisted state is read), there are problems unserializing the serialized data
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar -> C:\Java\jboss-4.0.4\server\test\tmp\deploy\tmp7332examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.SARDeployer at 153c375
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] about to copy 0 local directories
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, create step: url file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Registering service UCL=jmx.loading:UCL=46fef3
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.ServiceCreator] About to create xmbean object: example:service=ExampleService with code: example.ExampleService with embedded descriptor
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Loaded persistence mgr: org.jboss.mx.persistence.DelegatingPersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] init() --- ModelMBeanInfo Descriptor ---
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] descriptorType=mbean, displayName=org.jboss.mx.modelmbean.XMBean, log=F, name=org.jboss.mx.modelmbean.XMBean, objectname=(example:service=ExampleService), persistence-manager=org.jboss.mx.persistence.DelegatingPersistenceManager, persistPolicy=OnUpdate, resourceClass=example.ExampleService, visibility=1
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] chosen persistent id: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] using AttributePersistenceManager: org.jboss.system.pm.XMLAttributePersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] load() called for: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.pm.XMLAttributePersistenceManager] load(example:service=ExampleService)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.system.pm.XMLAttributePersistenceManager] Cannot deserialize object
> java.lang.ClassNotFoundException: example.ComplexAttribute
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584)
>     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
>     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
>     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
>     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.decodeFromHexString(XMLAttributePersistenceManager.java:738)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:440)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.persistence.DelegatingPersistenceManager] Caught exception while loading
> java.lang.Exception: Failed to deserialize attribute 'SomeAttribute'
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:443)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.server.registry.BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='example:service=ExampleService', Class=example.ExampleService (example.ExampleService at ae8af4)]
> 2006-08-01 14:33:59,329 INFO  [example.ExampleService] Registration is not done -> stop
> .

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:18:28 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Tue, 5 Sep 2006 08:18:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-697) First concurrent
 call doesn't throw exception
Message-ID: <23214189.1157458708176.JavaMail.jira@cloud.prod.atl2.jboss.com>

First concurrent call doesn't throw exception
---------------------------------------------

                 Key: EJBTHREE-697
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-697
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: Carlo de Wolf
            Priority: Critical
             Fix For: EJB 3.0 RC10 - FD


Concurrency check is in the server interceptor, while identity is established in the proxy after the first call. So if the first call is concurrent no exception is thrown. (see unit test concurrent)

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 10:48:29 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Tue, 5 Sep 2006 10:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1019)
 NoClassDefFoundError does not show up during portlet access
Message-ID: <29790682.1157467709772.JavaMail.jira@cloud.prod.atl2.jboss.com>

NoClassDefFoundError does not show up during portlet access
-----------------------------------------------------------

                 Key: JBPORTAL-1019
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1019
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 11:56:33 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Tue, 5 Sep 2006 11:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-748) Make
 JdbmCacheLoader use the
 standard binary format for persistent state transfer
In-Reply-To: <20953458.1156632011518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17175644.1157471793036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-748?page=all ]

Vladimir Blagojevic resolved JBCACHE-748.
-----------------------------------------

    Resolution: Done

> Make JdbmCacheLoader use the standard binary format for persistent state transfer
> ---------------------------------------------------------------------------------
>
>                 Key: JBCACHE-748
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-748
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0
>
>
> The state should be a sequence of NodeData objects; see FileCacheLoader or JDBCCacheLoader.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 11:56:33 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Tue, 5 Sep 2006 11:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1019)
 NoClassDefFoundError does not show up during portlet access
In-Reply-To: <29790682.1157467709772.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27993859.1157471793243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1019?page=all ]

Julien Viet resolved JBPORTAL-1019.
-----------------------------------

    Resolution: Done

> NoClassDefFoundError does not show up during portlet access
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1019
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1019
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 12:36:33 2006
From: jira-events at jboss.com (Ruel Loehr (JIRA))
Date: Tue, 5 Sep 2006 12:36:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <534788.1157474193376.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342834 ] 
            
Ruel Loehr commented on JBAS-3345:
----------------------------------

Tested this locally.  I removed the thirdparty tomcat dependencies and replaced them with jbossweb.   It is buildable.  Should be ready to changeover in the code and then address any testsuite issues.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 13:17:32 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 13:17:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-1) Move source
 repository from trunk to projects
Message-ID: <2995519.1157476652735.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move source repository from trunk to projects
---------------------------------------------

                 Key: SECURITY-1
                 URL: http://jira.jboss.com/jira/browse/SECURITY-1
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Repository
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Scott has expressed a desire to see the security project act as the model project to have a SPI and a JBossAS implementation. 

The first step in this exercize is to move the source repository from jbossas/trunk  to https://svn.jboss.org/repos/jbossas/projects/  (Reference will be the microcontainer project)



-- 
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

        


From jira-events at jboss.com  Tue Sep  5 13:43:28 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 13:43:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-2) Security Jars Into
 Thirdparty Repository
Message-ID: <27229725.1157478208545.JavaMail.jira@cloud.prod.atl2.jboss.com>

Security Jars Into Thirdparty Repository
----------------------------------------

                 Key: SECURITY-2
                 URL: http://jira.jboss.com/jira/browse/SECURITY-2
             Project: JBoss Security
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Repository
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


The JBoss Security Jars should be available via the thirdparty repository.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 14:25:30 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 14:25:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-2) Security Jars Into
 Thirdparty Repository
In-Reply-To: <27229725.1157478208545.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18850614.1157480730039.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-2?page=all ]

Anil Saldhana closed SECURITY-2.
--------------------------------

    Resolution: Done

jboss/security/snapshot available in thirdparty repository

> Security Jars Into Thirdparty Repository
> ----------------------------------------
>
>                 Key: SECURITY-2
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-2
>             Project: JBoss Security
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> The JBoss Security Jars should be available via the thirdparty repository.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 14:27:27 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 14:27:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-3) svn move of
 security from jbossas/trunk to jbossas/projects
Message-ID: <6196176.1157480847807.JavaMail.jira@cloud.prod.atl2.jboss.com>

svn move of security from jbossas/trunk to jbossas/projects
-----------------------------------------------------------

                 Key: SECURITY-3
                 URL: http://jira.jboss.com/jira/browse/SECURITY-3
             Project: JBoss Security
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Repository
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Perform a svn move of the security module from jbossas/trunk to jbossas/projects

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 14:35:28 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Tue, 5 Sep 2006 14:35:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1020) Replace direct
 uses of Log4J by JBoss logging.
Message-ID: <5738105.1157481328815.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace direct uses of Log4J by JBoss logging.
----------------------------------------------

                 Key: JBPORTAL-1020
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1020
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4 Final, 2.2 Branch
            Reporter: Chris Laprun
            Priority: Minor
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:23:28 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:23:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-536) The
 CallbackServer cannot be
 contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31980016.1157484208520.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic closed JBMESSAGING-536.
---------------------------------------

    Resolution: Done

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:23:28 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:23:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-536) The
 CallbackServer cannot
 be contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21386994.1157484208678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic reopened JBMESSAGING-536:
-----------------------------------------

             

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:25:31 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:25:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-536) The
 CallbackServer cannot be
 contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2891735.1157484331865.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic closed JBMESSAGING-536.
---------------------------------------

    Fix Version/s: 1.2.0.Alpha1
       Resolution: Done

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:45:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10897988.1157485529197.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=comments#action_12342855 ] 
            
Clebert Suconic commented on JBMESSAGING-499:
---------------------------------------------

the solution is really simple.

Just remove targetos=" windows" and ant would assume the current OS as default.

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:45:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28214344.1157485529333.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=comments#action_12342856 ] 
            
Clebert Suconic commented on JBMESSAGING-499:
---------------------------------------------

Tested this on both Windows (cygwin) and Linux BTW

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:49:30 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 5 Sep 2006 15:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6915110.1157485770473.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=comments#action_12342858 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-499:
---------------------------------------------

Please also try tests/bin/runtest, tests/bin/start-rmi-server and tests/bin/stop-rmi-server to make sure they work correctly from cygwin.

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:09:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 16:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11709750.1157486969252.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=all ]

Clebert Suconic closed JBMESSAGING-499.
---------------------------------------

    Fix Version/s: 1.2.0.Alpha1
       Resolution: Done

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:15:30 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 5 Sep 2006 16:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1006) Fix drag & drop
 code to work in IE
In-Reply-To: <9281802.1156994623979.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7855729.1157487330851.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1006?page=all ]

Roy Russo resolved JBPORTAL-1006.
---------------------------------

    Resolution: Done

> Fix drag & drop code to work in IE
> ----------------------------------
>
>                 Key: JBPORTAL-1006
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1006
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Internet Explorer
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Drag&drop javascript code currently works fine in Firefox. Check with Tomek.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:15:31 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 5 Sep 2006 16:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-536) The
 CallbackServer cannot
 be contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28658774.1157487331029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-536:
-----------------------------------------

             
Let's discuss the proper way to fix this here: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3969574#3969574

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:15:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 5 Sep 2006 16:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1021) Fix DnD code to
 work in JDK1.4_
Message-ID: <26516943.1157487331171.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix DnD code to work in JDK1.4_
-------------------------------

                 Key: JBPORTAL-1021
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1021
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:17:28 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 5 Sep 2006 16:17:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-990) AJAX lib to
 allow user positioning of windows
In-Reply-To: <25250425.1156182220833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30375101.1157487448995.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-990?page=all ]

Roy Russo resolved JBPORTAL-990.
--------------------------------

    Resolution: Done

The prototype is working. Additional tasks will follow wrt integration.

> AJAX lib to allow user positioning of windows
> ---------------------------------------------
>
>                 Key: JBPORTAL-990
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-990
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>
> Implement an AJAX lib to allow user positioning of windows.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 18:14:33 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Tue, 5 Sep 2006 18:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <19986179.1157494473619.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342894 ] 
            
Remy Maucherat commented on JBAS-3345:
--------------------------------------

Thanks for the testing.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 18:24:29 2006
From: jira-events at jboss.com (David Green (JIRA))
Date: Tue, 5 Sep 2006 18:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3624) <security-domain>
 setting in
 deployment descriptor populates @SecurityDomain annotation incorrectly on
 EJB3 session beans
Message-ID: <12582259.1157495069506.JavaMail.jira@cloud.prod.atl2.jboss.com>

<security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans
-------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3624
                 URL: http://jira.jboss.com/jira/browse/JBAS-3624
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: David Green
         Assigned To: Bill Burke


Specifying a <security-domain> in the jboss-app.xml incorrectly sets the @SecurityDomain on EJB3 session beans.

In the jboss-app.xml the security domain is specified as follows:

<jboss-app>
	<security-domain>java:/jaas/hch</security-domain>
</jboss-app>

In Ejb3DescriptorHandler the security-domain is copied directly into the SecurityDomainImpl instance as "java:/jaas/hch", however the @SecurityDomain annotation should be populated with the value "hch" (without the leading "java:/jaas/" prefix).  This causes the EJB3 session bean authentication to behave unexpectedly, since the authentication for the bean reverts to the default domain instead of the specified one.

The only way I've found to workaround this issue is to specify the @SecurityDomain individually on every session bean in the project.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 19:12:43 2006
From: jira-events at jboss.com (Christian Pekeler (JIRA))
Date: Tue, 5 Sep 2006 19:12:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
Message-ID: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>

NotificationBusDemo problem with 2.4CR2
---------------------------------------

                 Key: JGRP-299
                 URL: http://jira.jboss.com/jira/browse/JGRP-299
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4
         Environment: MacOSX, Java 1.5
            Reporter: Christian Pekeler
         Assigned To: Bela Ban


[/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
Starting NotificationBus with name BusDemo
Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
INFO: JGroups version: 2.4CR2
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
INFO: sockets will use interface 192.168.5.142
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
WARNING: traffic class of 8 could not be set, will be ignored
java.net.SocketException: Invalid argument
        at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
        at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
        at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
        at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
        at org.jgroups.protocols.UDP.start(UDP.java:383)
        at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
        at org.jgroups.stack.DownHandler.run(Protocol.java:118)
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
WARNING: traffic class of 8 could not be set, will be ignored
java.net.SocketException: Invalid argument
        at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
        at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
        at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
        at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
        at org.jgroups.protocols.UDP.start(UDP.java:383)
        at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
        at org.jgroups.stack.DownHandler.run(Protocol.java:118)
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 19:40:53 2006
From: jira-events at jboss.com (Michael Panoff (JIRA))
Date: Tue, 5 Sep 2006 19:40:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-189) XDoclet
 configuration dialog broken
Message-ID: <8333307.1157499653009.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-189?page=comments#action_12342910 ] 
            
Michael Panoff commented on JBIDE-189:
--------------------------------------

This issue is back with 1.6.0 GA.  Running on Mac OS 10.4.7 and Eclipse 3.2.0

> XDoclet configuration dialog broken
> -----------------------------------
>
>                 Key: JBIDE-189
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-189
>             Project: JBoss IDE
>          Issue Type: Bug
>    Affects Versions: 1.5 Milestone 1
>         Environment: Linux amd64, Eclipse 3.1RC1 (Build id: I20050527-1300), JBoss IDE 1.5M1 on BEA JRockit JDK1.5 (amd64)
>            Reporter: Sondre Eikanger Kval?
>         Assigned To: Marshall Culpepper
>            Priority: Blocker
>             Fix For: 1.5 Milestone 2
>
>
> In recent builds of Eclipse SDK, the XDoclet configuration dialog (project -> XDoclet Configuration) is broken.  When I try to open the dialog I get the error message "The currently displayed page contains invalid values".
> The error log (see below) reveals that this is caused by a ClassNotFoundException. The class in question is "org.eclipse.jdt.internal.ui.dialogs.StatusDialog". I've checked Eclipse CVS and found that this class was deleted from the repository (it exists in the 'attic'). The last log message says "switching to  org.eclipse.jface.dialogs.StatusDialog" (URL: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/dialogs/Attic/StatusDialog.java ). Maybe you guys should to :-)
> !ENTRY org.eclipse.osgi 2005-06-07 14:17:07.226
> !MESSAGE An error occured while automatically activating bundle org.jboss.ide.eclipse.deployer.ui (88).
> !STACK 0
> org.osgi.framework.BundleException: Exception in org.jboss.ide.eclipse.deployer.ui.DeployerUIPlugin.start() of bundle org.jboss.ide.eclipse.deployer.ui.
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1013)
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:969)
> 	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:321)
> 	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:266)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:112)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:275)
> 	at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
> 	at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1259)
> 	at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:152)
> 	at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:142)
> 	at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:129)
> 	at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:48)
> 	at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:240)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:51)
> 	at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:236)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition$1.run(LightweightDecoratorDefinition.java:111)
> 	at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1038)
> 	at org.eclipse.core.runtime.Platform.run(Platform.java:775)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.internalGetDecorator(LightweightDecoratorDefinition.java:107)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:218)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:67)
> 	at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1038)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/deployer/ui/dialogs/TargetEditDialog : org/eclipse/jdt/internal/ui/dialogs/StatusDialog
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown Source)
> Root exception:
> java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/deployer/ui/dialogs/TargetEditDialog : org/eclipse/jdt/internal/ui/dialogs/StatusDialog
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown 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

       



From jira-events at jboss.com  Tue Sep  5 22:56:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 5 Sep 2006 22:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3593) Add a Marshaller to
 HAPartitionImpl
In-Reply-To: <28592223.1157049918621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2895733.1157511403854.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3593?page=all ]

Brian Stansberry closed JBAS-3593.
----------------------------------

    Resolution: Done

> Add a Marshaller to HAPartitionImpl
> -----------------------------------
>
>                 Key: JBAS-3593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3593
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> HAPartitionImpl is quasi implementing Marshaller by overriding RpcDispatcher.handle() and doing custom *unmarshalling* with MarshalledValueInputStream.  This breaks with JG 2.4, since the default JG marshalling is different and incompatible with the custom unmarshalling.
> Solution to allow use of 2.4+ in 4.0.5+ is to properly implement Marshaller and do the marshalling as well.  This is done in HEAD; need to port to Branch_4_0.  The 4.0 marshaller must use the binary format of the old JGroups method to ensure backward interoperability.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 22:58:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 5 Sep 2006 22:58:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3592) Add system property
 jgroups.mcast.ip_ttl
In-Reply-To: <13362282.1157048839355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9187774.1157511524062.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3592?page=all ]

Brian Stansberry updated JBAS-3592:
-----------------------------------

    Summary: Add system property jgroups.mcast.ip_ttl  (was: Add system property jboss.mcast.ip.ttl)

> Add system property jgroups.mcast.ip_ttl
> ----------------------------------------
>
>                 Key: JBAS-3592
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3592
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Add a system property to all JGroups multicast configs in the AS to control ip_ttl.  Update testsuite build.xml to set this to 1 so running the testsuite doesn't send traffic off the box.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 23:56:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 23:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-536) The
 CallbackServer cannot be
 contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30876626.1157515003933.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic closed JBMESSAGING-536.
---------------------------------------

    Resolution: Done

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>          Time Spent: 1 day, 1 hour
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 00:04:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 00:04:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
Message-ID: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>

A testsuite testing client and server on different IPs
------------------------------------------------------

                 Key: JBMESSAGING-540
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
         Assigned To: Ovidiu Feodorov
             Fix For: 1.0.1.CR5


The current testsuite tests both client and server on the same network. 
We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 00:04:44 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 00:04:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
In-Reply-To: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3249311.1157515484118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-540?page=all ]

Clebert Suconic reassigned JBMESSAGING-540:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> A testsuite testing client and server on different IPs
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-540
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> The current testsuite tests both client and server on the same network. 
> We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 04:31:30 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:31:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1797) Need to investigate
 the ejb3 admin/monitoring requirements
Message-ID: <19936643.1157531490241.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1797?page=all ]

Dimitris Andreadis updated JBAS-1797:
-------------------------------------

      Component/s: EJB3
                       (was: EJB2)
    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

> Need to investigate the ejb3 admin/monitoring requirements
> ----------------------------------------------------------
>
>                 Key: JBAS-1797
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1797
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>             Fix For: JBossAS-5.0.0.CR1
>
>
> With the integration of the first j2ee5 technology into a jems product, we need to see what the integration issues are from the perspective of the jboss network admin and monitoring integration.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 04:39:32 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:39:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2330) Create Hibernate
 based timer persistence layer
Message-ID: <14997141.1157531972738.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2330?page=all ]

Dimitris Andreadis updated JBAS-2330:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Create Hibernate based timer persistence layer
> ----------------------------------------------
>
>                 Key: JBAS-2330
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2330
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> In the update of the timer service to support persistence independent of the server lifecycle, we should move to a hibernate based pm as opposed to screwing around with sql.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 04:41:30 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:41:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2407) EJB3 integration
Message-ID: <30143191.1157532090545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2407?page=all ]

Dimitris Andreadis updated JBAS-2407:
-------------------------------------

      Component/s: EJB3
                       (was: EJB2)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> EJB3 integration
> ----------------
>
>                 Key: JBAS-2407
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2407
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Need to review EJB3 integartion such that fixes/features don't get lost across EJB2.1/3.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

        


From jira-events at jboss.com  Wed Sep  6 04:41:30 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:41:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2848) Tool to analyze
 class loader consistency
Message-ID: <21802430.1157532090741.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2848?page=all ]

Dimitris Andreadis updated JBAS-2848:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Tool to analyze class loader consistency
> ----------------------------------------
>
>                 Key: JBAS-2848
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2848
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Since users don't generally care to think about the typesystem ramifications of the generally conflciting class loader setup allowed in ear deployments as evidenced in the associated forum thread, we need better out of the box smarter than the average deployment archive mess that creates an approriate canonical set of classpaths and class loader configuration. A first step is just a tool that identifies potential problems.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:11:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:11:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1288) Java5 Enum for mbean
 and configurations
Message-ID: <1388432.1157533891442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1288?page=all ]

Dimitris Andreadis updated JBAS-1288:
-------------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

> Java5 Enum for mbean and configurations
> ---------------------------------------
>
>                 Key: JBAS-1288
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1288
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.CR1
>
>
> Whenever you try to get a PropertyEditor for something but none is there, do the following additional check:
> if (type.getSuperclass().getName().equals("java.lang.Enum"))
> {
>    editor = new EnumPropertyEditor(type);
> }
> where the EnumPropertyEditor is:
> public class EnumPropertyEditor extends PropertyEditorSupport implements PropertyEditor
> {
>     private final Class targetType;
>     public EnumPropertyEditor(Class targetType)
>     {
>         this.targetType = targetType;
>     }
>     public void setAsText(String text) throws IllegalArgumentException
>     {
>         try
>         {
>             setValue(targetType.getMethod("valueOf",new Class[]{String.class}).invoke(null,new Object[]{text});
>         } catch (IllegalAccessException e)
>         {
>             throw new IllegalStateException(e);
>         } catch (InvocationTargetException e)
>         {
>             if (e.getTargetException() instanceof RuntimeException);
>                 throw (RuntimeException)e.getTargetException();
>             throw new IllegalStateException(e);
>         } catch (NoSuchMethodException e)
>         {
>             String err = type.getName() +
>                 " does not contain the required method: public static " +
>                  type.getName() + " valueOf(String);";
>             throw new IllegalArgumentException(err,e);
>         }
>         
>     }
>     public String getAsText()
>     {
>     	
>         try
>         {
>             return targetType.getMethod("name",null).invoke(getValue(),null)
>         } catch (IllegalAccessException e)
>         {
>             throw new IllegalStateException(e);
>         } catch (InvocationTargetException e)
>         {
>             if (e.getTargetException() instanceof RuntimeException);
>                 throw (RuntimeException)e.getTargetException();
>             throw new IllegalStateException(e);
>         } catch (NoSuchMethodException e)
>         {
>             String err = type.getName() +
>                 " does not contain the required method: public String name()";
>             throw new IllegalStateException(err,e);
>         }
>     }
> }

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:13:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-460) Make *-service.xml
	'validable'
Message-ID: <11238716.1157534011999.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-460?page=all ]

Dimitris Andreadis updated JBAS-460:
------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Make *-service.xml 'validable'
> ------------------------------
>
>                 Key: JBAS-460
>                 URL: http://jira.jboss.com/jira/browse/JBAS-460
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>    Affects Versions: JBossAS-4.0.0 Final
>            Reporter: SourceForge User
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: hanming .
> A little while back, I reported this bug:
> https://sourceforge.net/tracker/?func=detail&atid=376685&aid=715680&group_id=22866
> It brought jboss-service_3_2.dtd closer to what David
> Jencks has in mind:
> "we do not have a dtd for *-service files because
> attributes can have xml
>  element values.  AFAIK the only way to cater to this
> is with namespaces and
>  xml schema.  We may need to do this for jboss 4.
>  basically...
>  <depends optional-attribute-name="foo">[object name or
> another mbean
>  dd]</depends>
>  and
>  <depends-list optional-attribute-name="bar">
>    <depends-list-element>[o-n or mbean
> dd]</depends-list-element>
>    <depends-list-element>[o-n or mbean
> dd]</depends-list-element>
>  ...
>  </depends-list>"
> jboss-service_3_2.dtd is as good a DTD as in reflecting
> what David has in mind but it has a major problem: it
> can never be used to validate any *-service.xml file.
> This is because XML 1.0 can never have this kind of
> construct (represented here as using DTD language, as
> opposed to Schema because it cannot be represented
> using the latter):
> <!ELEMENT depends (#PCDATA | mbean)>
> The closest that one can come up with is
> <!ELEMENT depends (#PCDATA | mbean)*>
> This is how XML 1.0 (may XML 1.1 changes it, I don't
> know) deal with a class of SGML problem known as the
> 'pernicious mixed content". Search Google for more details.
> http://www.w3.org/TR/REC-xml#sec-mixed-content
> Summary:
> ---------------
> I know it's too late to change anything for 3.2 but I
> have suggestions for 4.0
> 1. Don't use mixed content, if possible. It's easy to
> get it wrong in different level: API, parsing and
> writing of DTDs/Schemas.
> 2. The easiest local workaround for the element
> <depends> is to use Element wrapper pattern, e.g:
> <!ELEMENT depends-content (#PCDATA)>
> <!ELEMENT depends (depends-content | mbean)>
> But that might not be a good overall solution.
> 3. Bear in mind that XML Schema in designed to work
> with XML 1.0, hence the closest one can use Schema to
> constraint <depends> is:
>   <xs:element name="depends">
>     <xs:complexType mixed="true">
>       <xs:choice>
>         <xs:element ref="mbean"/>
>       </xs:choice>
>       <xs:attribute name="optional-attribute-name"
> type="xs:string"/>
>     </xs:complexType>
>   </xs:element>
> which is not really what David's original intention is.
> Thank you, Han Ming

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:17:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:17:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2148) ServerInfo MBean
 operations return HTML code as java.lang.String
Message-ID: <14903458.1157534257847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2148?page=all ]

Dimitris Andreadis closed JBAS-2148.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Rejected

Won't deal with this, unless someone wants to contribute.

> ServerInfo MBean operations return HTML code as java.lang.String
> ----------------------------------------------------------------
>
>                 Key: JBAS-2148
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2148
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: Fedora Core 4 (x86-32bit)
> JDK5.0_04
> unmodified minimal server configuration
> System.properties from: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMBeansInJConsole
>            Reporter: Mikko Tiihonen
>            Priority: Minor
>
> The ServerInfo MBean which can be viewed through the Java 5.0 jconsole returns responses to operations as Strings that contain HTML code.
> Instead of <TABLE><TR><TD>... etc the operations should return objects that implement MBean interface or they should be split to smaller operations that can show simple objects.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:21:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:21:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3167) Support Pack200
 compression for WAR/EAR files to reduce upload time
Message-ID: <5847090.1157534493829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3167?page=all ]

Dimitris Andreadis updated JBAS-3167:
-------------------------------------

        Fix Version/s:     (was: JBossAS-4.0.5.GA)
    Affects Version/s: JBossAS-4.0.2 Final
                           (was: JBossAS-4.0.4.CR2)

If someone wants to prototype this fine, but for now there are no cycles for it.

> Support Pack200 compression for WAR/EAR files to reduce upload time
> -------------------------------------------------------------------
>
>                 Key: JBAS-3167
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3167
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: n/a
>            Reporter: Richard Kennard
>            Priority: Optional
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> First, thank you for such an outstanding Application Server: JBoss is truly a magnificent piece of software that is an absolute joy to work with. You guys are a shining testament to the quality of Open Source.
> My feature request is to support Sun's new(ish) Pack200 compression format for WARs and EARs. I know precious little about this, other than it is built into the JRE and can pack JARs to a fraction of their original size. I'm not even sure it can be applied 'as is' to WARs and EARs, so perhaps this can be a proprietary JBoss feature?
> Anyway, at 20MB+ an EAR takes a good 10-15 minutes to upload to my hosting service using my home broadband connection, so any move to help reduce EAR size would be a boon.
> I understand that Pack200 JARs must first be uncompressed into JARs before they can be used, but this should be fairly natural for JBoss (which uncompresses into the tmp folder anyway, I believe).

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 06:13:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 06:13:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3625) Update
Message-ID: <13328214.1157537614191.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update 
-------

                 Key: JBAS-3625
                 URL: http://jira.jboss.com/jira/browse/JBAS-3625
             Project: JBoss Application Server
          Issue Type: 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

        


From jira-events at jboss.com  Wed Sep  6 06:17:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 06:17:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3625) Update EJB3 for
	jboss-4.0.5.GA
In-Reply-To: <13328214.1157537614191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8755598.1157537853399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3625?page=all ]

Dimitris Andreadis updated JBAS-3625:
-------------------------------------

              Summary: Update EJB3 for jboss-4.0.5.GA  (was: Update )
          Component/s: EJB3
        Fix Version/s: JBossAS-4.0.5.GA
    Affects Version/s: JBossAS-4.0.5.CR1
          Description: Merge EJB3 changes to Branch_4_0, take care of any library dependency issues (e.g. new remoting version required?)
             Assignee: Bill Burke

> Update EJB3 for jboss-4.0.5.GA
> ------------------------------
>
>                 Key: JBAS-3625
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3625
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> Merge EJB3 changes to Branch_4_0, take care of any library dependency issues (e.g. new remoting version required?)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 06:29:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 06:29:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3626) Upgrade jbossws to
	1.0.4.GA
Message-ID: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jbossws to 1.0.4.GA
---------------------------

                 Key: JBAS-3626
                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


Upgrade to jbossws-1.0.4.GA, when it becomes available

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 06:47:29 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Wed, 6 Sep 2006 06:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3627) Write test to test
 rollback of a NACK in 2PC
Message-ID: <22340756.1157539649297.JavaMail.jira@cloud.prod.atl2.jboss.com>

Write test to test rollback of a NACK in 2PC
--------------------------------------------

                 Key: JBAS-3627
                 URL: http://jira.jboss.com/jira/browse/JBAS-3627
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMS service
            Reporter: Luc Texier
         Assigned To: Adrian Brock
             Fix For: JBossAS-4.0.5.GA


Need to test BasicQueue.acknowledge()
whether it should also add a PostRollback task for a NACK under a transaction.

i.e. 

      // Was it a negative acknowledge??
      if (!item.isAck)
      {
         Runnable task = new RestoreMessageTask(m);
         server.getPersistenceManager().getTxManager().addPostCommitTask(txId, task);
+         server.getPersistenceManager().getTxManager().addPostRollbackjTask(txId, task);
      }

The  hard part is wrting such a test since it is a normal condition.
Probably need to use direct invocation on the server invoker ?

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 07:01:29 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Wed, 6 Sep 2006 07:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3628) Invalid fix for
	JBAS-3573
Message-ID: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invalid fix for JBAS-3573
-------------------------

                 Key: JBAS-3628
                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Luc Texier
         Assigned To: Luc Texier
             Fix For: JBossAS-4.0.5.GA



in case of an exception, both  a PostCommit Task and a PostRollback Task should be added

         try
         {
            if (m.isPersistent())
               server.getPersistenceManager().remove(m, txId);
         }
         catch (Throwable t)
         {
            // Something is wrong with the persistence manager,
            // force a NACK with a rollback/error
            Runnable task = new RestoreMessageTask(m);
            TxManager txManager = server.getPersistenceManager().getTxManager();
+          txManager.addPostCommitTask(txId, task);            
            txManager.addPostRollbackTask(txId, task);
            SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Wed Sep  6 07:46:28 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 07:46:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3586) Upgrade Tomcat to
	Version 5.5.18
In-Reply-To: <15166838.1156950344122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7159289.1157543188301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3586?page=all ]

Dimitris Andreadis closed JBAS-3586.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis  (was: Anil Saldhana)

Updated Branch_4_0.

> Upgrade Tomcat to Version 5.5.18
> --------------------------------
>
>                 Key: JBAS-3586
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3586
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> We have to ensure that Tomcat needs to be upgraded to the latest version available at the release of 4.0.5.GA
> Just before the release happens and this issue is being closed, we need to update the *title* of this JIRA issue to indicate the correct version of Tomcat that is included.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:10:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:10:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2133) use left join in
 jboss-3.2.7 with oracle8.1.7.0.1
Message-ID: <22776571.1157544633352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2133?page=all ]

Dimitris Andreadis updated JBAS-2133:
-------------------------------------

       Issue Type: Feature Request  (was: Bug)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> use left join in jboss-3.2.7 with oracle8.1.7.0.1
> -------------------------------------------------
>
>                 Key: JBAS-2133
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2133
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: fedora core 3 ,jrockit 1.4.2_05
>            Reporter: peixubin
>             Fix For: JBossAS-4.0.6.CR1
>
>
> I have this jbossquery:
> <query-method>
> <method-name>findByCounte</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </query-method>
> <jboss-ql><![CDATA[SELECT OBJECT(o) FROM JhFyck o WHERE o.counte.name=?1]]></jboss-ql>
> <read-ahead>
> on-find
> <eager-load-group>*</eager-load-group>
> <left-join cmr-field="jhFyk" eager-load-group="*"/>
> </read-ahead>
> while I execute this find method,the console print errors:
> 10:35:44,374 DEBUG [JhFyck#findByCounte] Executing SQL: SELECT t0_o.PKID, t0_o.FYLX, t0_o.RKSJ, t0_o.RKR, t0_o.CWM, t0_o.FYH, t0_o.FYK, t0_o.RKPC, t0_o.RCPC, t0_o.ZT, t0_o.BFR, t0_o.BFSJ, t1 _o_jhFyk.PKID, t1_o_jhFyk.P_PKID, t1_o_jhFyk.MC, t1_o_jhFyk.BM, t1_o_jhFyk.X, t1_o_jhFyk.Y, t1_ o_jhFyk.ZT FROM PXB.JH_FYCK t0_o, YD.COUNTE t2_o_counte, JH_COUNTE_FY t3_o_counte_RELATION_TABLE LEFT OUTER JOIN PXB.JH_FYK t1_o_jhFyk ON t0_o.FYK=t1_o_jhFyk.PKID WHERE (t2_o_counte.NAME = ? AND t0_o.PKID=t3_o_counte_RELATION_TABLE.FYBH AND t2_o_counte.NAME=t3_o_counte_RELATION_TABLE. COUNTE)
> 10:35:44,405 ERROR [JhFyck#findByCounte] Find failed
> java.sql.SQLException: ORA-00933: SQL command not properly ended
> at oracle.jdbc.dbaccess.DBError.throwSqlException(Ljava.lang.String;Ljava.lang.String;I )V(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError()V(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive()V(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(BBI[B[Loracle.jdbc.dbaccess.DBType;[Loracle.jd bc.dbaccess.DBData;I[Loracle.jdbc.dbaccess.DBType;[Loracle.jdbc.dbaccess.DBData;I)V(TTC7Protoco l.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(Loracle.jdbc.dbaccess.DBStatement ;[BLoracle.jdbc.dbaccess.DBDataSet;)[Loracle.jdbc.dbaccess.DBColumn;(TTC7Protocol.java:643)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery()V(OracleStatement.java:1674)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout()V(OracleStatement.java:1870 )
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate()I(OraclePreparedStatement. java:363)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery()Ljava.sql.ResultSet;(Oracle PreparedStatement.java:314)
> at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery()Ljava.sql.Res ultSet;(WrappedPreparedStatement.java:314)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(Ljava.lang.String;[L java.lang.Object;IILorg.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;Lorg.jboss.ejb.plugi ns.cmp.jdbc.bridge.JDBCCMPFieldBridge;Lorg.jboss.ejb.plugins.cmp.ejbql.SelectFunction;Lorg.jbos s.ejb.plugins.cmp.jdbc.JDBCStoreManager;[ZLjava.util.List;Ljava.util.List;Lorg.jboss.ejb.plugin s.cmp.jdbc.metadata.JDBCQueryMetaData;Lorg.jboss.ejb.GenericEntityObjectFactory;Lorg.jboss.logg ing.Logger;)Ljava.util.Collection;(JDBCAbstractQueryCommand.java:226)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(Ljava.lang.reflect.M ethod;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObj ectFactory;)Ljava.util.Collection;(JDBCAbstractQueryCommand.java:128)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(Ljava.lang.reflect.Me thod;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObje ctFactory;)Ljava.util.Collection;(JDBCFindEntitiesCommand.java:40)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(Ljava.lang.reflect.Meth od;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObject Factory;)Ljava.util.Collection;(JDBCStoreManager.java:598)
> at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(Ljava.lang.reflect.Method;[ Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObjectFact ory;)Ljava.util.Collection;(CMPPersistenceManager.java:278)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntities(Ljava. lang.reflect.Method;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.Ge nericEntityObjectFactory;)Ljava.util.Collection;(CachedConnectionInterceptor.java:325)
> at org.jboss.ejb.EntityContainer.findLocal(Lorg.jboss.invocation.Invocation;)Ljava.lang .Object;(EntityContainer.java:609)
> at jrockit.reflect.NativeMethodInvoker.invoke0(Ljava.lang.Object;ILjava.lang.Object;[Lj ava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> at jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Lja va.lang.Object;(Unknown Source)
> at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Obje ct;)Ljava.lang.Object;(Unknown Source)
> at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Ob ject;(Unknown Source)
> at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(Lorg.jboss.invocation. Invocation;)Ljava.lang.Object;(EntityContainer.java:1066)
> at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(Lorg.jboss.invocation.Invocatio n;)Ljava.lang.Object;(AbstractInterceptor.java:88)
> at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(Lorg.jboss.invocat ion.Invocation;)Ljava.lang.Object;(EntitySynchronizationInterceptor.java:204)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(Lorg.jbo ss.invocation.Invocation;)Ljava.lang.Object;(CachedConnectionInterceptor.java:215)
> at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(Lorg.jboss.invocation.Invocatio n;)Ljava.lang.Object;(AbstractInterceptor.java:88)
> at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(Lorg.jboss.invocation.Inv ocation;)Ljava.lang.Object;(EntityInstanceInterceptor.java:97)
> at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(Lorg.jboss.invocation.Invocat ion;)Ljava.lang.Object;(EntityLockInterceptor.java:61)
> at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(Lorg.jboss.invocation.Inv ocation;)Ljava.lang.Object;(EntityCreationInterceptor.java:28)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Lorg.jboss.invocation.Invocat ion;Z)Ljava.lang.Object;(AbstractTxInterceptor.java:88)
> at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(Lorg.jboss.invocation.Inv ocation;)Ljava.lang.Object;(TxInterceptorCMT.java:317)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(Lorg.jboss.invocation.Invocation;) Ljava.lang.Object;(TxInterceptorCMT.java:130)
> Oracle not support left join syntax,how to configure jboss to use oracle-style left-join?

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:20:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2222) Add support to
 LdapExtLoginModule for user searches that return a referral
Message-ID: <20945409.1157545229186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2222?page=all ]

Dimitris Andreadis updated JBAS-2222:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Move feature requests to the next release

> Add support to LdapExtLoginModule for user searches that return a referral
> --------------------------------------------------------------------------
>
>                 Key: JBAS-2222
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2222
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The current LdapExtLoginModule cannot handle a user search that returns a referral. We need to look into supporting following the referral to authenticate the user against the target server.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:20:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2831) Allow run-as
 indentity propagation across servers with configurable trust
Message-ID: <23700617.1157545229526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2831?page=all ]

Dimitris Andreadis updated JBAS-2831:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Move new feature requests to the next release.

> Allow run-as indentity propagation across servers with configurable trust
> -------------------------------------------------------------------------
>
>                 Key: JBAS-2831
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2831
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4RC1
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Look to provide propagation of the run-as identity across server calls with control over how the target server trusts this call is correct.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:24:28 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:24:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2243)
 UsernamePassword/DatabaseServerLoginModule reveal to much information
Message-ID: <22574264.1157545468205.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2243?page=all ]

Dimitris Andreadis updated JBAS-2243:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> UsernamePassword/DatabaseServerLoginModule reveal to much information
> ---------------------------------------------------------------------
>
>                 Key: JBAS-2243
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2243
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: 4.0.3RC2/EJB3
>            Reporter: Jens Elkner
>
> If an authentication fails, the thrown javax.security.auth.login.FailedLoginException has a detailed message, which says "Password Incorrect/Password Required" or "No matching username found in Principals". These are pretty good information for an attacker, since than it knows, where to continue its attack and is able to skip a lot of tasks (no matter, whether it comes from the internal or external network - in our days, attacks from internal is probably the most common case). 
> Actually, that's also the reason, why many authentication systems just insert even a delay to not let the attacker guess, whether the guessed username was wrong or the guessed password (minimal, but measurable delay dueto en/decryption) ...
> So, logging those details might be ok, but revealing those infos to the client is without any doubt a security issue!

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:34:36 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-12) Release WS-Context
 implementation and re-factor
Message-ID: <13184349.1157549676054.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-12?page=all ]

Mark Little updated JBESB-12:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Release WS-Context implementation and re-factor
> -----------------------------------------------
>
>                 Key: JBESB-12
>                 URL: http://jira.jboss.com/jira/browse/JBESB-12
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.1
>
>
> The ESB architecture has a notion of a message context. In Web Services, the standard approach for this is OASIS WS-Context. Although our ESB is not tied to Web Services, it makes sense that we should support WS-Context. We already have an implementation that has been tested for interoperability with IONA and Oracle, so this is a good starting point. It will need some updating to bring it in line with the latest version of the specification.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:52:28 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:52:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-86) Identify what QA and
 unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28864816.1157550748768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-86?page=all ]

Mark Little updated JBESB-86:
-----------------------------

    Assignee: Tom Fennelly  (was: Mark Little)

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 09:54:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-113) Improve
	documentation
In-Reply-To: <5394662.1154687171848.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10415300.1157550870988.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-113?page=comments#action_12342938 ] 
            
Mark Little commented on JBESB-113:
-----------------------------------

This is an ongoing task. Will close as a result.

> Improve documentation
> ---------------------
>
>                 Key: JBESB-113
>                 URL: http://jira.jboss.com/jira/browse/JBESB-113
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> The programmers guide for the beta needs improving, with much more explicit information on classes, what they are for, how they are used and configuration information. What we have for the beta release will require augmentation via the forums and that is not an ideal situation.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:54:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:54:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-113) Improve documentation
In-Reply-To: <5394662.1154687171848.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24836539.1157550871091.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-113?page=all ]

Mark Little closed JBESB-113.
-----------------------------

    Resolution: Done

> Improve documentation
> ---------------------
>
>                 Key: JBESB-113
>                 URL: http://jira.jboss.com/jira/browse/JBESB-113
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> The programmers guide for the beta needs improving, with much more explicit information on classes, what they are for, how they are used and configuration information. What we have for the beta release will require augmentation via the forums and that is not an ideal situation.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:56:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-120) ObjectStore
 configured differently from other components
In-Reply-To: <8533363.1154951052094.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5788660.1157550991229.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-120?page=all ]

Mark Little updated JBESB-120:
------------------------------

    Assignee: Kurt Stam  (was: Mark Little)

> ObjectStore configured differently from other components
> --------------------------------------------------------
>
>                 Key: JBESB-120
>                 URL: http://jira.jboss.com/jira/browse/JBESB-120
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.0
>
>
> Why does the object store configuration work differently from other components? Specifically, it doesn't use the ParamsRepository approach.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:56:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-123) Remove hardcoded
	class names
In-Reply-To: <1140887.1155045312458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24231562.1157550991415.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-123?page=all ]

Mark Little updated JBESB-123:
------------------------------

    Assignee: Daniel Brum  (was: Mark Little)

> Remove hardcoded class names
> ----------------------------
>
>                 Key: JBESB-123
>                 URL: http://jira.jboss.com/jira/browse/JBESB-123
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0
>
>
>       Class oCls = Class.forName("org.jboss.soa.esb.util.BobjStdDTO");

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:56:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-15) Basic transformation
 integration using Smooks
Message-ID: <16675567.1157550992311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-15?page=all ]

Mark Little updated JBESB-15:
-----------------------------

    Component/s: Transformation Service
                     (was: ESB Core)

> 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
>             Fix For: 4.0
>
>
> 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

        


From jira-events at jboss.com  Wed Sep  6 09:56:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-22) Transformation
	service interface
Message-ID: <13160685.1157550992706.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-22?page=all ]

Mark Little updated JBESB-22:
-----------------------------

    Component/s: Transformation Service

> Transformation service interface
> --------------------------------
>
>                 Key: JBESB-22
>                 URL: http://jira.jboss.com/jira/browse/JBESB-22
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transformation Service
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>             Fix For: 4.0
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> We need to agree on the interface (in the forum) and then provide it/them.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:58:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-62) Change jar names
Message-ID: <1940883.1157551111769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-62?page=all ]

Mark Little updated JBESB-62:
-----------------------------

    Component/s: Distribution

> Change jar names
> ----------------
>
>                 Key: JBESB-62
>                 URL: http://jira.jboss.com/jira/browse/JBESB-62
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 09:58:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-134) Content-based
	routing support
In-Reply-To: <14800145.1155656179686.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18514089.1157551111927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-134?page=all ]

Mark Little updated JBESB-134:
------------------------------

    Component/s: Content Based Routing
                     (was: ESB Core)

> Content-based routing support
> -----------------------------
>
>                 Key: JBESB-134
>                 URL: http://jira.jboss.com/jira/browse/JBESB-134
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Content Based Routing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 09:58:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-21) Registry service
	interface
Message-ID: <7967047.1157551111652.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-21?page=all ]

Mark Little updated JBESB-21:
-----------------------------

    Component/s: Registry
                     (was: ESB Core)

> Registry service interface
> --------------------------
>
>                 Key: JBESB-21
>                 URL: http://jira.jboss.com/jira/browse/JBESB-21
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Registry
>            Reporter: Mark Little
>         Assigned To: Mugdho
>             Fix For: 4.0
>
>
> We need a registry. It cannot be WS specific, but JAX-R looks like it still matches. Check out what is available in JBossWS (or elsewhere). Assuming we go the JAX-R route (discuss on forum please), then we need stand-alone JAX-R support and a plugin.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:04:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:04:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6038807.1157551472423.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little updated JBESB-104:
------------------------------

    Assignee: Daniel Brum  (was: Mark Little)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:04:32 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 6 Sep 2006 10:04:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-649)
 IdentityLock.getFqn() always returns Fqn.ROOT
Message-ID: <19030567.1157551472560.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-649?page=comments#action_12342941 ] 
            
Brian Stansberry commented on JBCACHE-649:
------------------------------------------

Please note that this issue was to fix an issue that cropped up during 1.4 development.  The problem was never in any released version of JBoss Cache, not even a beta.

> IdentityLock.getFqn() always returns Fqn.ROOT
> ---------------------------------------------
>
>                 Key: JBCACHE-649
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-649
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 1.4.0
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Somewhere along the way the fqn field got removed from IdentityLock, and getFqn() got hardcoded to always return Fqn.ROOT.  This leads to misleading exception messages and log statements like "org.jboss.cache.lock.TimeoutException: read lock for / could not be acquired by ..."  -- when actually the problem was on "/JSESSON/localhost".  Just spent an hour on a fruitless search for who could have a WL on "/" .

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:04:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:04:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-60) Place non-public
 classes and interfaces into internal package structure
Message-ID: <29447246.1157551472759.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-60?page=all ]

Mark Little updated JBESB-60:
-----------------------------

    Assignee: Esteban Schifman  (was: Mark Little)

> Place non-public classes and interfaces into internal package structure
> -----------------------------------------------------------------------
>
>                 Key: JBESB-60
>                 URL: http://jira.jboss.com/jira/browse/JBESB-60
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:06:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-58) Add back EPR
	functionality
Message-ID: <27983204.1157551593029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-58?page=all ]

Mark Little updated JBESB-58:
-----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]
    Priority: Critical  (was: Major)

> Add back EPR functionality
> --------------------------
>
>                 Key: JBESB-58
>                 URL: http://jira.jboss.com/jira/browse/JBESB-58
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> Prior to Rosetta, the Alpha 1 codebase has the EPR capabilities. Add this back.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:06:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-59) Add in generic bus
	abstraction
Message-ID: <26143891.1157551593161.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-59?page=all ]

Mark Little updated JBESB-59:
-----------------------------

    Priority: Critical  (was: Major)

> Add in generic bus abstraction
> ------------------------------
>
>                 Key: JBESB-59
>                 URL: http://jira.jboss.com/jira/browse/JBESB-59
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> Prior to Rosetta, we had the notion of a generic bus with client/service plugins, dispatchers and a message format. All of this needs to be added back to the new codebase.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:06:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-48) I18N/L10N compliance
Message-ID: <29853481.1157551593377.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-48?page=all ]

Mark Little updated JBESB-48:
-----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.)]
    Priority: Optional  (was: Major)

> I18N/L10N compliance
> --------------------
>
>                 Key: JBESB-48
>                 URL: http://jira.jboss.com/jira/browse/JBESB-48
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Optional
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:08:31 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 6 Sep 2006 10:08:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-649)
 IdentityLock.getFqn() always returns Fqn.ROOT
Message-ID: <2226008.1157551711994.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-649?page=comments#action_12342942 ] 
            
Brian Stansberry commented on JBCACHE-649:
------------------------------------------

Previous comment incorrect; it was broken in 1.4.0.Alpha and 1.4.0.Beta, fixed in 1.4.0.Beta2.

> IdentityLock.getFqn() always returns Fqn.ROOT
> ---------------------------------------------
>
>                 Key: JBCACHE-649
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-649
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 1.4.0
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Somewhere along the way the fqn field got removed from IdentityLock, and getFqn() got hardcoded to always return Fqn.ROOT.  This leads to misleading exception messages and log statements like "org.jboss.cache.lock.TimeoutException: read lock for / could not be acquired by ..."  -- when actually the problem was on "/JSESSON/localhost".  Just spent an hour on a fruitless search for who could have a WL on "/" .

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:08:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:08:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-39) Add more QA and unit
	tests
Message-ID: <17171849.1157551712181.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-39?page=all ]

Mark Little updated JBESB-39:
-----------------------------

    Priority: Critical  (was: Major)

> Add more QA and unit tests
> --------------------------
>
>                 Key: JBESB-39
>                 URL: http://jira.jboss.com/jira/browse/JBESB-39
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 week, 4 minutes
>  Remaining Estimate: 0 minutes
>
> The Rosetta codebase does not come with a lot of tests. We need a lot more before the beta release and certainly for the 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

        


From jira-events at jboss.com  Wed Sep  6 10:08:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:08:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-119) Parameter loading
 doesn't check for XML validity
In-Reply-To: <7780536.1154950212823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7450909.1157551712324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-119?page=all ]

Mark Little updated JBESB-119:
------------------------------

    Priority: Critical  (was: Major)

> Parameter loading doesn't check for XML validity
> ------------------------------------------------
>
>                 Key: JBESB-119
>                 URL: http://jira.jboss.com/jira/browse/JBESB-119
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> The current ParamRepository approach has a File implementation. It all appears to work on Strings (with the comments indicating how the strings should be formatted for structured attributes). However, some user classes assume the String is XML. Parameters should be provided to application classes through name/value pairs. How those pairs are loaded into the system (XML, strings, file, etc.) should be hidden.
> We also need an ESB schema.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:08:32 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 6 Sep 2006 10:08:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-15) Basic
 transformation integration using Smooks
Message-ID: <26368879.1157551712485.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-15?page=comments#action_12342943 ] 
            
Tom Fennelly commented on JBESB-15:
-----------------------------------

Will start by integrating it into the existing Rosetta architecture.  This will change considerably once the "ultimate" architecture is evolved.

> 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
>             Fix For: 4.0
>
>
> 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

        


From jira-events at jboss.com  Wed Sep  6 10:10:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-122) Schema needed
In-Reply-To: <17213696.1154955972421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2655231.1157551831290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-122?page=all ]

Mark Little updated JBESB-122:
------------------------------

    Priority: Critical  (was: Major)

> Schema needed
> -------------
>
>                 Key: JBESB-122
>                 URL: http://jira.jboss.com/jira/browse/JBESB-122
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:10:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-22) Transformation
	service interface
Message-ID: <24782726.1157551831488.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-22?page=all ]

Mark Little updated JBESB-22:
-----------------------------

    Priority: Critical  (was: Major)

> Transformation service interface
> --------------------------------
>
>                 Key: JBESB-22
>                 URL: http://jira.jboss.com/jira/browse/JBESB-22
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transformation Service
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> We need to agree on the interface (in the forum) and then provide it/them.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:10:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1021) Fix DnD code to
 work in JDK1.4_
In-Reply-To: <26516943.1157487331171.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18379052.1157551831614.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1021?page=all ]

Roy Russo resolved JBPORTAL-1021.
---------------------------------

    Resolution: Done

> Fix DnD code to work in JDK1.4_
> -------------------------------
>
>                 Key: JBPORTAL-1021
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1021
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-21) Registry service
	interface
Message-ID: <26920387.1157551950222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-21?page=all ]

Mark Little updated JBESB-21:
-----------------------------

    Priority: Critical  (was: Major)

> Registry service interface
> --------------------------
>
>                 Key: JBESB-21
>                 URL: http://jira.jboss.com/jira/browse/JBESB-21
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Registry
>            Reporter: Mark Little
>         Assigned To: Mugdho
>            Priority: Critical
>             Fix For: 4.0
>
>
> We need a registry. It cannot be WS specific, but JAX-R looks like it still matches. Check out what is available in JBossWS (or elsewhere). Assuming we go the JAX-R route (discuss on forum please), then we need stand-alone JAX-R support and a plugin.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-134) Content-based
	routing support
In-Reply-To: <14800145.1155656179686.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7188541.1157551950528.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-134?page=all ]

Mark Little updated JBESB-134:
------------------------------

    Priority: Critical  (was: Major)

> Content-based routing support
> -----------------------------
>
>                 Key: JBESB-134
>                 URL: http://jira.jboss.com/jira/browse/JBESB-134
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Content Based Routing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Critical
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30963434.1157551950783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little updated JBESB-104:
------------------------------

    Priority: Critical  (was: Major)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>            Priority: Critical
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-15) Basic transformation
 integration using Smooks
Message-ID: <15617767.1157551950959.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-15?page=all ]

Mark Little updated JBESB-15:
-----------------------------

    Priority: Critical  (was: Major)

> 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
>
>
> 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

        


From jira-events at jboss.com  Wed Sep  6 10:12:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-55) Nightly builds of
	unit tests
Message-ID: <7166526.1157551951126.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-55?page=all ]

Mark Little updated JBESB-55:
-----------------------------

    Priority: Critical  (was: Minor)

> Nightly builds of unit tests
> ----------------------------
>
>                 Key: JBESB-55
>                 URL: http://jira.jboss.com/jira/browse/JBESB-55
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Critical
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:14:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:14:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-135) Integration with
 Microcontainer (IoC abstraction)
Message-ID: <11365425.1157552071692.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integration with Microcontainer (IoC abstraction)
-------------------------------------------------

                 Key: JBESB-135
                 URL: http://jira.jboss.com/jira/browse/JBESB-135
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Kevin Conner
            Priority: Critical
             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:26:31 2006
From: jira-events at jboss.com (Matias Zaya Mendez (JIRA))
Date: Wed, 6 Sep 2006 10:26:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-475) Error in
 documentation concerning the joining of constarints
Message-ID: <21882515.1157552791961.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error in documentation concerning the joining of constarints
------------------------------------------------------------

                 Key: JBRULES-475
                 URL: http://jira.jboss.com/jira/browse/JBRULES-475
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 3.0.4
            Reporter: Matias Zaya Mendez
         Assigned To: Mark Proctor
            Priority: Trivial


In the documentation it is specified that in the DSL in order to create join constraints you define them as such:
(URL:http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/3.0.4/html_single/index.html)

[when]There is a Cheese with=Cheese()
[when]-age is less than {age}=age<{age}
[when]-type is '{type}'=type=='{type}'
[when]-country equal to '{country}'=country=='{country}'

Actually, there must be a space between the "dash" and the constraint, such as:

[when]There is a Cheese with=Cheese()
[when]- age is less than {age}=age<{age}
[when]- type is '{type}'=type=='{type}'
[when]- country equal to '{country}'=country=='{country}'

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:30:34 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1007) Fix drag & drop
 code to work in Konqueror
In-Reply-To: <2383186.1156994624285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24345669.1157553034767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1007?page=all ]

Roy Russo resolved JBPORTAL-1007.
---------------------------------

    Resolution: Done

> Fix drag & drop code to work in Konqueror
> -----------------------------------------
>
>                 Key: JBPORTAL-1007
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1007
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Konqueror
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> check with Tomek.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:30:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 10:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <10618400.1157553035307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic reassigned JBAS-2299:
-------------------------------------

    Assignee: Clebert Suconic

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:30:36 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:30:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1010) Window drag&drop
In-Reply-To: <24406364.1156995464631.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18520688.1157553036351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1010?page=all ]

Roy Russo reassigned JBPORTAL-1010:
-----------------------------------

    Assignee: Roy Russo

> Window drag&drop
> ----------------
>
>                 Key: JBPORTAL-1010
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1010
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> placeholder super-task for all drag&drop tasks

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:32:30 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 6 Sep 2006 10:32:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-22) Transformation
	service interface
Message-ID: <8112623.1157553150768.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-22?page=comments#action_12342946 ] 
            
Tom Fennelly commented on JBESB-22:
-----------------------------------

Where are we with this at the minute:
1. Forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81237,  http://www.jboss.org/index.html?module=bb&op=viewtopic&t=82506
2. Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=TransformationServices

> Transformation service interface
> --------------------------------
>
>                 Key: JBESB-22
>                 URL: http://jira.jboss.com/jira/browse/JBESB-22
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transformation Service
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> We need to agree on the interface (in the forum) and then provide it/them.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:32:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:32:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1022) Remove
 unecessary ui libs from DnD code
Message-ID: <24899762.1157553151522.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove unecessary ui libs from DnD code
---------------------------------------

                 Key: JBPORTAL-1022
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1022
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:54:35 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:54:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1022) Remove
 unecessary ui libs from DnD code
In-Reply-To: <24899762.1157553151522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <616831.1157554475374.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1022?page=all ]

Roy Russo resolved JBPORTAL-1022.
---------------------------------

    Resolution: Done

> Remove unecessary ui libs from DnD code
> ---------------------------------------
>
>                 Key: JBPORTAL-1022
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1022
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:07:29 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Wed, 6 Sep 2006 11:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14248950.1157555250003.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Luc Texier updated JBAS-3628:
-----------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
      Description: 
in case of an exception, both  a PostCommit Task and a PostRollback Task should be added

         try
         {
            if (m.isPersistent())
               server.getPersistenceManager().remove(m, txId);
         }
         catch (Throwable t)
         {
            // Something is wrong with the persistence manager,
            // force a NACK with a rollback/error
            Runnable task = new RestoreMessageTask(m);
            TxManager txManager = server.getPersistenceManager().getTxManager();
+          txManager.addPostCommitTask(txId, task);            
            txManager.addPostRollbackTask(txId, task);
            SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, t);
         }

  was:

in case of an exception, both  a PostCommit Task and a PostRollback Task should be added

         try
         {
            if (m.isPersistent())
               server.getPersistenceManager().remove(m, txId);
         }
         catch (Throwable t)
         {
            // Something is wrong with the persistence manager,
            // force a NACK with a rollback/error
            Runnable task = new RestoreMessageTask(m);
            TxManager txManager = server.getPersistenceManager().getTxManager();
+          txManager.addPostCommitTask(txId, task);            
            txManager.addPostRollbackTask(txId, task);
            SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, t);
         }


> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Luc Texier
>         Assigned To: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Wed Sep  6 11:09:33 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 6 Sep 2006 11:09:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-476) DSL constraint
 appending needs to be tolerant of spaces
Message-ID: <28700414.1157555373009.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL constraint appending needs to be tolerant of spaces
-------------------------------------------------------

                 Key: JBRULES-476
                 URL: http://jira.jboss.com/jira/browse/JBRULES-476
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.4
            Reporter: Michael Neale
         Assigned To: Michael Neale


If you do

[when]-foo bar=Baz()

it will fail to expand unless you put a space after the "-".

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:09:33 2006
From: jira-events at jboss.com (Brice Ruth (JIRA))
Date: Wed, 6 Sep 2006 11:09:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-745) Add <action> to JPDL
 docs for create-timer
Message-ID: <19490009.1157555373312.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add <action> to JPDL docs for create-timer
------------------------------------------

                 Key: JBPM-745
                 URL: http://jira.jboss.com/jira/browse/JBPM-745
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Documentation
    Affects Versions:  jBPM 3.1.2, jBPM 3.1.1, jBPM 3.1
            Reporter: Brice Ruth
         Assigned To: Tom Baeyens
            Priority: Minor


See http://docs.jboss.org/jbpm/v3/userguide/jpdl.html#create.timer.element

Much the same as defining a <timer /> in jpdl, <create-timer></create-timer> supports a nested <action /> element. This should be appropriately referenced/linked in the documentation in this section.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:23:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:23:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-121) Check recovery
Message-ID: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>

Check recovery
--------------

                 Key: JBTM-121
                 URL: http://jira.jboss.com/jira/browse/JBTM-121
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:49:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:49:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-117) release notes for
 JTS talk about context interceptor
In-Reply-To: <4031051.1155223512756.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16274931.1157557772637.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-117?page=comments#action_12342951 ] 
            
Mark Little commented on JBTM-117:
----------------------------------

This is done in HEAD, just not in the branch.

> release notes for JTS talk about context interceptor
> ----------------------------------------------------
>
>                 Key: JBTM-117
>                 URL: http://jira.jboss.com/jira/browse/JBTM-117
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Should update to talk about interposition interceptor.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:49:32 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 11:49:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-38) Interoperability demo
Message-ID: <22910854.1157557772825.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-38?page=comments#action_12342952 ] 
            
Kevin Conner commented on JBTM-38:
----------------------------------

The work involved writing the following parts
 - the protocol supporting the WS-TX1.1 AT and Coordination specifications
 - a web application responsible for initiating the AT interop tests
 - a web service responsible for the participant side of the tests
 - an HTTP proxy responsible for logging and orchestrating some tests

All tests were successfully executed against the other organisations taking part in the interop.

> Interoperability demo
> ---------------------
>
>                 Key: JBTM-38
>                 URL: http://jira.jboss.com/jira/browse/JBTM-38
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>          Time Spent: 1 week, 4 days
>  Remaining Estimate: 0 minutes
>
> Demonstrate interoperability with IBM and Microsoft. Important for the specification as well as our product.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:51:28 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 11:51:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-38) Interoperability demo
Message-ID: <22227402.1157557888424.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-38?page=all ]

Kevin Conner closed JBTM-38.
----------------------------

    Resolution: Done

> Interoperability demo
> ---------------------
>
>                 Key: JBTM-38
>                 URL: http://jira.jboss.com/jira/browse/JBTM-38
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>          Time Spent: 1 week, 4 days
>  Remaining Estimate: 0 minutes
>
> Demonstrate interoperability with IBM and Microsoft. Important for the specification as well as our product.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:57:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-37) Modifications for the
 OASIS Standard
Message-ID: <33243128.1157558250827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-37?page=all ]

Mark Little updated JBTM-37:
----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)])
    Assignee: Kevin Conner  (was: Mark Little)

> Modifications for the OASIS Standard
> ------------------------------------
>
>                 Key: JBTM-37
>                 URL: http://jira.jboss.com/jira/browse/JBTM-37
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.4
>
>
> Preliminary support for the OASIS WS-TX standard.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:59:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:59:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-111) Check QA into CVS
In-Reply-To: <19381808.1154158031400.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18175359.1157558373940.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-111?page=all ]

Mark Little updated JBTM-111:
-----------------------------

    Fix Version/s: 4.6
                       (was: 4.4)

> Check QA into CVS
> -----------------
>
>                 Key: JBTM-111
>                 URL: http://jira.jboss.com/jira/browse/JBTM-111
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.6
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:59:34 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:59:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-108) Make number of
 transactions rolled back per reaper sweep configurable
In-Reply-To: <15698701.1154089451341.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6885444.1157558374053.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-108?page=all ]

Mark Little updated JBTM-108:
-----------------------------

    Fix Version/s: 4.6
                       (was: 4.4)

> Make number of transactions rolled back per reaper sweep configurable
> ---------------------------------------------------------------------
>
>                 Key: JBTM-108
>                 URL: http://jira.jboss.com/jira/browse/JBTM-108
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      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.6
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:59:34 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:59:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-37) Modifications for the
 OASIS Standard
Message-ID: <9143827.1157558374231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-37?page=all ]

Mark Little updated JBTM-37:
----------------------------

    Fix Version/s: 4.6
                       (was: 4.4)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)])

> Modifications for the OASIS Standard
> ------------------------------------
>
>                 Key: JBTM-37
>                 URL: http://jira.jboss.com/jira/browse/JBTM-37
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.6
>
>
> Preliminary support for the OASIS WS-TX standard.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 12:01:30 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 12:01:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-122) Requalify WS-TX 1.0
 interop against IBM/Microsoft endpoints
Message-ID: <33145092.1157558490997.JavaMail.jira@cloud.prod.atl2.jboss.com>

Requalify WS-TX 1.0 interop against IBM/Microsoft endpoints
-----------------------------------------------------------

                 Key: JBTM-122
                 URL: http://jira.jboss.com/jira/browse/JBTM-122
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: WS-T Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 12:03:30 2006
From: jira-events at jboss.com (Colin Walters (JIRA))
Date: Wed, 6 Sep 2006 12:03:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-619) PojoCache to
 support JDK5.0 Enum
Message-ID: <24839643.1157558610658.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-619?page=comments#action_12342953 ] 
            
Colin Walters commented on JBCACHE-619:
---------------------------------------

So as I understand it, without this bug fix it is not possible to use enum values in entity objects
when using the EJB3 entity cache?

Is there a workaround?  

I found this JIRA from this forum thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71311&view=previous

> PojoCache to support JDK5.0 Enum
> --------------------------------
>
>                 Key: JBCACHE-619
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-619
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 12:05:30 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 12:05:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-37) Modifications for
 the OASIS Standard
Message-ID: <7982374.1157558730537.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-37?page=comments#action_12342954 ] 
            
Kevin Conner commented on JBTM-37:
----------------------------------

The protocol for the OASIS WS-TX 1.1 AtomicTransaction and Coordination specifications was written as part of JBTM-38.  This still has to be integrated into the current WS-TX implementation.

> Modifications for the OASIS Standard
> ------------------------------------
>
>                 Key: JBTM-37
>                 URL: http://jira.jboss.com/jira/browse/JBTM-37
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.6
>
>
> Preliminary support for the OASIS WS-TX standard.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 13:05:37 2006
From: jira-events at jboss.com (Antoine Herzog (JIRA))
Date: Wed, 6 Sep 2006 13:05:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5852451.1157562337100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12342959 ] 
            
Antoine Herzog commented on JBPORTAL-1004:
------------------------------------------

In the doc, it is said : rebuild the jboss portal to change the "portal" first item in the url.
Could be possible to do it more simply ?
when starting, we don't want to touch that. After trying the portal and build our environnement (cms configuration....) and new portlets, it seem heavy to rebuild from the begining.
May be only make some documentation about how to change thing without rebuilding the whole thing ?
(open another issue for this ?)


> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 14:05:34 2006
From: jira-events at jboss.com (Jerry Gauthier (JIRA))
Date: Wed, 6 Sep 2006 14:05:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-470) Update JBoss Cache
 to use JGroups 2.4 and Multiplexer
Message-ID: <22130465.1157565934531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Jerry Gauthier closed JBCACHE-470.
----------------------------------

    Resolution: Done

Multiplexer integration has been enabled for JBossCache 2.0.  Documentation has been updated and sample configuration files have been modified to demonstrate how to configure the multiplxer with JBossCache.

> Update JBoss Cache to use JGroups 2.4 and Multiplexer
> -----------------------------------------------------
>
>                 Key: JBCACHE-470
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-470
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>         Assigned To: Jerry Gauthier
>            Priority: Blocker
>             Fix For: 2.0.0
>
>
> Use a ChannelFactory that looks up the MBean server to potentially create a JGroups multiplexer channel

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 14:23:29 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 6 Sep 2006 14:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-1) Move source
 repository from trunk to projects
In-Reply-To: <2995519.1157476652735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5726783.1157567009405.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-1?page=all ]

Anil Saldhana updated SECURITY-1:
---------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90069

> Move source repository from trunk to projects
> ---------------------------------------------
>
>                 Key: SECURITY-1
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-1
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Scott has expressed a desire to see the security project act as the model project to have a SPI and a JBossAS implementation. 
> The first step in this exercize is to move the source repository from jbossas/trunk  to https://svn.jboss.org/repos/jbossas/projects/  (Reference will be the microcontainer project)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:05:33 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Wed, 6 Sep 2006 15:05:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-190) web app generation
	tool
Message-ID: <29778645.1157569533527.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-190?page=comments#action_12342968 ] 
            
Alejandro Guizar commented on BPEL-190:
---------------------------------------

Actually, WSDL includes a binding for HTTP's GET and POST methods, so that apps other than web browsers are able to interact with a web site. This binding makes an html-based webapp a formal webservice. The ex-CEO probably did not realize how right he was :-)

The WSDL spec URL: http://www.w3.org/TR/wsdl#_http

As useful as it could be, potentially saving years of typing into HTML forms, it lacks support in WS stacks. Even Apache WSIF does not support the HTTP binding. Most works focus on the SOAP binding and leave other bindings out.

So many paths, so little time :-\

> web app generation tool
> -----------------------
>
>                 Key: BPEL-190
>                 URL: http://jira.jboss.com/jira/browse/BPEL-190
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 1
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> create a tool for generating web application artifacts

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:16:28 2006
From: jira-events at jboss.com (Jim Moran (JIRA))
Date: Wed, 6 Sep 2006 15:16:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3629)
 org.jboss.naming.ExternalContext.SerializableInitialContext should be
 included in [jboss]/client/jbossall-client.jar
Message-ID: <13965861.1157570188405.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.naming.ExternalContext.SerializableInitialContext should be included in [jboss]/client/jbossall-client.jar
--------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3629
                 URL: http://jira.jboss.com/jira/browse/JBAS-3629
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Build System, Naming
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Jim Moran
         Assigned To: Ruel Loehr
            Priority: Minor


org.jboss.naming.ExternalContext.SerializableInitialContext exists in server/default/lib/jboss.jar but it does not exist for a client that uses [jboss]/client/jbossall-client.jar.
As a result if a client app needs to lookup an ExternalContext on a remote JBoss instance, the client must enable RMI classloader or include server/default/lib/jboss.jar
It would be nicer if ExternalContext was included with jbossall-client.jar

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:36:28 2006
From: jira-events at jboss.com (Stephen Parry (JIRA))
Date: Wed, 6 Sep 2006 15:36:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-361) When creating entity
 bean, multiple radio buttons from the same group are checked
Message-ID: <33423178.1157571388696.JavaMail.jira@cloud.prod.atl2.jboss.com>

When creating entity bean, multiple radio buttons from the same group are checked
---------------------------------------------------------------------------------

                 Key: JBIDE-361
                 URL: http://jira.jboss.com/jira/browse/JBIDE-361
             Project: JBoss IDE
          Issue Type: Bug
    Affects Versions: 1.6
         Environment: Windows XP SP2 JBoss 4.0.4 GA Eclipse 3.1.2 IDE 1.6.0 from update site
            Reporter: Stephen Parry


- Added new J2EE 1.4 project JiraTest with source folder src with output bin
- Added new package: jiratest.ejb
- Right click on package, select New -> Other -> Entity Bean
New Entity Bean wizard appears, but the radio buttons are 'confused'; both CMP 1.x and CMP 2.x are selected and both Remote and Local are selected, but not Both (!).


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:48:29 2006
From: jira-events at jboss.com (Todd Main (JIRA))
Date: Wed, 6 Sep 2006 15:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-343) Action method of
 source page being executed after destination action
Message-ID: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>

Action method of source page being executed after destination action
--------------------------------------------------------------------

                 Key: JBSEAM-343
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
             Project: JBoss Seam
          Issue Type: Bug
          Components: JSF
    Affects Versions: 1.0.1
         Environment: Windows XP, jboss installation per Seam setup instructions
            Reporter: Todd Main


I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:

Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".

   <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>

There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.

                            <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
                                <f:param name="dayRange" value="7" />
                                <f:param name="documentCategory" value="po" />
                                #{quickClicksData.ordersFromLastSeven}
                            </s:link>

When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.

Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:

This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is

Code:

   
   public boolean callPageActions(PhaseEvent event)
   {
      Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
      boolean actionsWereCalled = false;
      try
      {
         actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
         actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
         return actionsWereCalled;

The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.

If the code were
Code:

    actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
    actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
    return actionsWereCalled;
	


that should fix this.


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:50:29 2006
From: jira-events at jboss.com (Mauro Lopez (JIRA))
Date: Wed, 6 Sep 2006 15:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-344) Portal booking
 example loses conversation after validation error
Message-ID: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portal booking example loses conversation after validation error
----------------------------------------------------------------

                 Key: JBSEAM-344
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
             Project: JBoss Seam
          Issue Type: Bug
          Components: Portal
    Affects Versions: 1.0.1
         Environment: JBoss 4.0.4.GA
JBoss Portal 2.4.0-Beta1
(used jems-installer-1.2.0.BETA)
JBoss Seam 1.0.1.GA
            Reporter: Mauro Lopez


Followed this steps:
- deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
- Entered http://localhost:8080/portal
- Selected the SeamHibernate portlet tab, registered user, logged in...
- Searched hotels, selected one of them, and pressed the "Book" button.

In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 

So, after a failed validation, the conversation is lost.

In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 16:22:38 2006
From: jira-events at jboss.com (Chris Mercer (JIRA))
Date: Wed, 6 Sep 2006 16:22:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-6) Archive Browser
 does not support jar:file: url protocol
Message-ID: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>

Archive Browser does not support jar:file: url protocol
-------------------------------------------------------

                 Key: JBCOMMON-6
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-6
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: core
         Environment: jdk 1.5.8
jboss 4.0.4ga
hibernate 3.2cr2
hibernate entity manager 3.2.0.CR1
Using ejb3/entity manager annotations
            Reporter: Chris Mercer
         Assigned To: Dimitris Andreadis
            Priority: Critical


We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.


Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
	... 148 more


org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  

This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  

I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 16:22:38 2006
From: jira-events at jboss.com (Chris Mercer (JIRA))
Date: Wed, 6 Sep 2006 16:22:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-7) Archive Browser
 does not support jar:file: url protocol
Message-ID: <13191915.1157574158355.JavaMail.jira@cloud.prod.atl2.jboss.com>

Archive Browser does not support jar:file: url protocol
-------------------------------------------------------

                 Key: JBCOMMON-7
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-7
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: core
         Environment: jdk 1.5.8
jboss 4.0.4ga
hibernate 3.2cr2
hibernate entity manager 3.2.0.CR1
Using ejb3/entity manager annotations
            Reporter: Chris Mercer
         Assigned To: Dimitris Andreadis
            Priority: Critical


We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.


Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
	... 148 more


org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  

This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  

I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 16:26:28 2006
From: jira-events at jboss.com (Chris Mercer (JIRA))
Date: Wed, 6 Sep 2006 16:26:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-7) Archive Browser does
 not support jar:file: url protocol
In-Reply-To: <13191915.1157574158355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30188855.1157574388894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-7?page=all ]

Chris Mercer closed JBCOMMON-7.
-------------------------------

    Resolution: Duplicate Issue

submitted twice on accident

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: JBCOMMON-7
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-7
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:04:29 2006
From: jira-events at jboss.com (David Green (JIRA))
Date: Wed, 6 Sep 2006 17:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-698) Exception
 serialization issue when remotely accessing stateless session bean
Message-ID: <23517647.1157576669733.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception serialization issue when remotely accessing stateless session bean
----------------------------------------------------------------------------

                 Key: EJBTHREE-698
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-698
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: David Green


Accessing a remote EJB (Session bean) results in exception.  Stack trace follows:

13:54:39,546 ERROR [SocketClientInvoker] Got marshalling exception, exiting
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
	at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
	at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
	at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
	at org.jboss.remoting.Client.invoke(Client.java:525)
	at org.jboss.remoting.Client.invoke(Client.java:488)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
	at $Proxy0.postNotification(Unknown Source)
	at com.hgea.hch.service.HchClientDelegate.postNotification(HchClientDelegate.java:99)
	at com.hgea.hch.client.RemoteHchClientTest.testRemotePostNotification(RemoteHchClientTest.java:38)
	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:597)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:18:32 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 6 Sep 2006 17:18:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
In-Reply-To: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15451824.1157577512202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-299?page=all ]

Bela Ban resolved JGRP-299.
---------------------------

    Resolution: Done

Looks like your JVM doesn't support setting this option. I therefore recommend you remove the tos="8" line from your config file

> NotificationBusDemo problem with 2.4CR2
> ---------------------------------------
>
>                 Key: JGRP-299
>                 URL: http://jira.jboss.com/jira/browse/JGRP-299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: MacOSX, Java 1.5
>            Reporter: Christian Pekeler
>         Assigned To: Bela Ban
>
> [/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
> Starting NotificationBus with name BusDemo
> Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
> INFO: JGroups version: 2.4CR2
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> INFO: sockets will use interface 192.168.5.142
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:24:30 2006
From: jira-events at jboss.com (Christian Pekeler (JIRA))
Date: Wed, 6 Sep 2006 17:24:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
In-Reply-To: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27778124.1157577870531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-299?page=comments#action_12342976 ] 
            
Christian Pekeler commented on JGRP-299:
----------------------------------------

It did work without error on my JVM (Java 1.5 on Mac OS X 10.4.7) with 2.4CR1 and earlier versions.

> NotificationBusDemo problem with 2.4CR2
> ---------------------------------------
>
>                 Key: JGRP-299
>                 URL: http://jira.jboss.com/jira/browse/JGRP-299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: MacOSX, Java 1.5
>            Reporter: Christian Pekeler
>         Assigned To: Bela Ban
>
> [/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
> Starting NotificationBus with name BusDemo
> Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
> INFO: JGroups version: 2.4CR2
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> INFO: sockets will use interface 192.168.5.142
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:44:28 2006
From: jira-events at jboss.com (Antoine Herzog (JIRA))
Date: Wed, 6 Sep 2006 17:44:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32546559.1157579068483.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12342977 ] 
            
Antoine Herzog commented on JBPORTAL-1004:
------------------------------------------

It is in the documentation of 2.4. 
this comment is useless. sorry.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:31 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <25867620.1157580031568.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment:     (was: new_splash_left_aligned.jpg)

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:31 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <25669011.1157580031733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment: ide_spotlight_v3progress.jpg

OK, we got the new image that covers the new product name "JBossIDE for Eclipse" and includes good spacing/alignment for the progress bar and loading message. Check out the attached JPG.. looks nice and pretty =). Issue should now be considered resolved..

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:31 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <16643286.1157580031938.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper resolved JBIDE-332.
--------------------------------------

    Fix Version/s: 2.0.0.Beta2
       Resolution: Done

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:32 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <13808712.1157580032102.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment:     (was: ide_spotlight_v3progress.jpg)

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:32 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <1213257.1157580032265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment: new_splash_left_aligned.jpg

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:44:43 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 6 Sep 2006 18:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1023) Use cookies to
 deal with sessions instead of SessionContext
Message-ID: <31796742.1157582683797.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use cookies to deal with sessions instead of SessionContext
-----------------------------------------------------------

                 Key: JBPORTAL-1023
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1023
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:44:43 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 6 Sep 2006 18:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1023) Use cookies to
 deal with sessions instead of SessionContext
In-Reply-To: <31796742.1157582683797.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30928461.1157582683866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1023?page=all ]

Chris Laprun resolved JBPORTAL-1023.
------------------------------------

    Fix Version/s: 2.6.Alpha1
       Resolution: Done

> Use cookies to deal with sessions instead of SessionContext
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1023
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1023
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:03:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 19:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-424) Cannot
 access the first message when starting the JMS subscriber
Message-ID: <4355164.1157583823765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-424?page=comments#action_12342983 ] 
            
Clebert Suconic commented on JBMESSAGING-424:
---------------------------------------------

I have added org.jboss.test.messaging.jms.crash.DurableCrash1 and org.jboss.test.messaging.jms.crash.DurableCrash2.

To execute this combined test, execute ant crash-tests on testsuite. (when I posted this commented it was commited on Branch_1 only, I will commit it to Trunk as soon as we decide the test is valid)

> Cannot access the first message when starting the JMS subscriber
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-424
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-424
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: JBoss jboss-4.0.4.GA & jboss-messaging-1.0.1.CR2 
>            Reporter: Seung Hyun
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Some messages are already published to the specific queue and the queue contains few messages. Starts the subscriber to receive the messages in the queue. It reads all the messages except the first message. Also, the first message is not accessible at all.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:03:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 19:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-424) Cannot access
 the first message when starting the JMS subscriber
Message-ID: <21384372.1157583823914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-424?page=all ]

Clebert Suconic updated JBMESSAGING-424:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> Cannot access the first message when starting the JMS subscriber
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-424
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-424
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: JBoss jboss-4.0.4.GA & jboss-messaging-1.0.1.CR2 
>            Reporter: Seung Hyun
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Some messages are already published to the specific queue and the queue contains few messages. Starts the subscriber to receive the messages in the queue. It reads all the messages except the first message. Also, the first message is not accessible at all.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:07:27 2006
From: jira-events at jboss.com (Ivelin Ivanov (JIRA))
Date: Wed, 6 Sep 2006 19:07:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <16090713.1157584047380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342984 ] 
            
Ivelin Ivanov commented on JBAS-3345:
-------------------------------------

great. let's make the switch.


> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:21:27 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Wed, 6 Sep 2006 19:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-350) create
 specification for jbossws/jbosside plugin / integration
In-Reply-To: <30880297.1155172032601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6619104.1157584887930.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-350?page=comments#action_12342985 ] 
            
Max Andersen commented on JBIDE-350:
------------------------------------

i'm a WS noob, but one thing I definitly would "assume" is that we would hook into/support WTP WS integration....and if not at least find out why it can't/won't be done ;)

> create specification for jbossws/jbosside plugin / integration
> --------------------------------------------------------------
>
>                 Key: JBIDE-350
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-350
>             Project: JBoss IDE
>          Issue Type: Task
>          Components: Webservices Plugin
>            Reporter: Ole Matzura
>         Assigned To: Ole Matzura
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossWS Eclipse Plugin Specification.doc
>
>
> we need a spec that outlines how jbossws should be integrated into eclipse/jbosside

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:54:43 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Wed, 6 Sep 2006 19:54:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <33174856.1157586883946.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342986 ] 
            
Remy Maucherat commented on JBAS-3345:
--------------------------------------

There are indeed some testsuite issues.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 02:39:26 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 02:39:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
In-Reply-To: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4106313.1157611166630.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-299?page=comments#action_12342999 ] 
            
Bela Ban commented on JGRP-299:
-------------------------------

Then try setting it to back to 16

> NotificationBusDemo problem with 2.4CR2
> ---------------------------------------
>
>                 Key: JGRP-299
>                 URL: http://jira.jboss.com/jira/browse/JGRP-299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: MacOSX, Java 1.5
>            Reporter: Christian Pekeler
>         Assigned To: Bela Ban
>
> [/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
> Starting NotificationBus with name BusDemo
> Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
> INFO: JGroups version: 2.4CR2
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> INFO: sockets will use interface 192.168.5.142
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:19:28 2006
From: jira-events at jboss.com (Maurice Zeijen (JIRA))
Date: Thu, 7 Sep 2006 03:19:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-345) correct ejb-jar.xml
 root node declaration in examples
Message-ID: <16305010.1157613568524.JavaMail.jira@cloud.prod.atl2.jboss.com>

correct ejb-jar.xml root node declaration in examples
-----------------------------------------------------

                 Key: JBSEAM-345
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-345
             Project: JBoss Seam
          Issue Type: Task
          Components: Examples
    Affects Versions: 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1, 1.1
            Reporter: Maurice Zeijen
            Priority: Minor


Please correct the root node decleration in the seam examples. At this moment they only contain the <ejb-jar> node but this should be:

<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.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

        


From jira-events at jboss.com  Thu Sep  7 03:19:28 2006
From: jira-events at jboss.com (Stephen Friedrich (JIRA))
Date: Thu, 7 Sep 2006 03:19:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-346) Full <ejb-jar>
 declaration in examples' ejb-jar.xml files
Message-ID: <27019148.1157613568758.JavaMail.jira@cloud.prod.atl2.jboss.com>

Full <ejb-jar> declaration in examples' ejb-jar.xml files
---------------------------------------------------------

                 Key: JBSEAM-346
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-346
             Project: JBoss Seam
          Issue Type: Task
          Components: Examples
    Affects Versions: 1.0.1
            Reporter: Stephen Friedrich


Currently ejb-jar.xml files in seam examples (1.0.1 GA) use just "<ejb-jar>".

Would be nicer if they used a full, standard compliant declaration:
{code}
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.0">	
{code}

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:37:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 03:37:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-300) NAKACK.send() doesn't
 need to be synchronized
Message-ID: <9351729.1157614648499.JavaMail.jira@cloud.prod.atl2.jboss.com>

NAKACK.send() doesn't need to be synchronized
---------------------------------------------

                 Key: JGRP-300
                 URL: http://jira.jboss.com/jira/browse/JGRP-300
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.4


NAKACK.send() currently calls passDown(evt) in a synchronized(sent_msgs) statement. However, this is not necessary (contrary to handleMessage() which needs to pass messages up in the order of sequence numbers) because messages can be sent un-ordered. The receivers will order the messages anyway, so if we sent 1,3,2,4 due to thread premption, the receivers will order them and deliver them as 1,2,3,4.
BENEFIT: the less synchronization, the less probability of deadlocks

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:41:29 2006
From: jira-events at jboss.com (Maurice Zeijen (JIRA))
Date: Thu, 7 Sep 2006 03:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
Message-ID: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
------------------------------------------------------------------------------------

                 Key: JBSEAM-347
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1, 1.1
         Environment: JBoss 4.0.4 GA
JBoss Portal 2.4
MyFaces 1.1.3
            Reporter: Maurice Zeijen
            Priority: Critical


I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 

My configuration details are below the exception.

Code:

23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
java.lang.IllegalStateException: No active session context
	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
agedPersistencePortletPhaseListener.java:53)
	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
.java:89)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)

	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)

	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
va:143)
	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
ceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
r.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
SessionSynchronizationInterceptor.java:76)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
ContextDispatcherInterceptor.java:124)
	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
rInterceptor.java:68)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
terceptor.java:74)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
tor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
eptor.java:65)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
14)
	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy65.invoke(Unknown Source)
	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
a:249)
	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy67.invoke(Unknown Source)
	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
rvice.java:139)
	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
Service.java:155)
	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy69.invoke(Unknown Source)
	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
ssionSynchronizationInterceptor.java:85)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
r.java:93)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
tor.java:83)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy51.invoke(Unknown Source)
	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
rceptor.java:171)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
tor.java:80)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
terceptor.java:79)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
:59)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
rceptor.java:171)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
tor.java:80)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
terceptor.java:79)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
:59)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
	at $Proxy161.handle(Unknown Source)
	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
4)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
terceptor.java:92)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
xt(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
xt(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)

	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
Protocol.java:664)
	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
	at java.lang.Thread.run(Thread.java:595)


Here are the config files:

Components.xml
Code:

<components>

    <component name="org.jboss.seam.core.init">
    	<property name="debug">true</property>
        <property name="myFacesLifecycleBug">false</property>
        <property name="jndiPattern">@jndiPattern@</property>
    </component>
    
    <!-- 120 second conversation timeout -->
    <component name="org.jboss.seam.core.manager">
        <property name="conversationTimeout">120000</property>
    </component>
    
    <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>

</components>
	



components.properties
Code:

embeddedEjb false
jndiPattern TestPortlet/#{ejbName}/local
	



faces-config.xml
Code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE faces-config 
    PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
    "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

	<!-- Navigation rules for the Booking demo app -->
	
	<navigation-rule>
		<from-view-id>*</from-view-id>
		<navigation-case>
			<from-outcome>view</from-outcome>
			<to-view-id>/view.xhtml</to-view-id>
		</navigation-case>
	</navigation-rule>
	
	<navigation-rule>
		<from-view-id>*</from-view-id>
		<navigation-case>
			<from-outcome>edit</from-outcome>
			<to-view-id>/edit.xhtml</to-view-id>
		</navigation-case>
	</navigation-rule>
	
	<navigation-rule>
		<from-view-id>*</from-view-id>
		<navigation-case>
			<from-outcome>help</from-outcome>
			<to-view-id>/help.xhtml</to-view-id>
		</navigation-case>
	</navigation-rule>

	<application>
		<view-handler>
			com.sun.facelets.FaceletPortletViewHandler
		</view-handler>
	</application>

	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->

	<lifecycle>
		<phase-listener>
			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
		</phase-listener>
	</lifecycle>

</faces-config>
	



web.xml
Code:

<?xml version="1.0" encoding="UTF-8"?>
<web-app> 

	 <!-- ### Seam  ######################################################################################
######### -->
   
    <listener>
        <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
    </listener>
	
    <!-- Propagate conversations across redirects -->
    <filter>
        <filter-name>Seam Redirect Filter</filter-name>
        <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
    </filter>
    
    <filter-mapping>
        <filter-name>Seam Redirect Filter</filter-name>
        <url-pattern>*.seam</url-pattern>
    </filter-mapping>
    
    <filter-mapping>
        <filter-name>Seam Redirect Filter</filter-name>
        <url-pattern>*.xhtml</url-pattern>
    </filter-mapping>
    
    <!-- ### JSF ########################################################################################
####### -->
    
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>

    <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
    </context-param>

    <context-param>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>true</param-value>
    </context-param>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
	
	 <!-- ### MY FACES ###################################################################################
############ -->
    
	
	<context-param>
		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
		<param-value>true</param-value>
		<description>
		    This parameter tells MyFaces if javascript code should be allowed in the
		    rendered HTML output.
		    If javascript is allowed, command_link anchors will have javascript code
		    that submits the corresponding form.
		    If javascript is not allowed, the state saving info and nested parameters
		    will be added as url parameters.
		    Default: "true"
		    </description>
	</context-param>

	<context-param>
		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
		<param-value>false</param-value>
		<description>
		    This parameter tells MyFaces if javascript code should be allowed in the
		    rendered HTML output.
		    If javascript is allowed, command_link anchors will have javascript code
		    that submits the corresponding form.
		    If javascript is not allowed, the state saving info and nested parameters
		    will be added as url parameters.
		    Default: "false"
	
		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
		    best results.
	
		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
low to get
		    JavaScript detection working.
		    </description>
	</context-param>

	<context-param>
		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
		<param-value>true</param-value>
		<description>
		    If true, rendered HTML code will be formatted, so that it is "human readable".
		    i.e. additional line separators and whitespace will be written, that do not
		    influence the HTML code.
		    Default: "true"
		</description>
	</context-param>

	<context-param>
		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
		<param-value>true</param-value>
		<description>
		    If true, a javascript function will be rendered that is able to restore the
		    former vertical scroll on every request. Convenient feature if you have pages
		    with long lists and you do not want the browser page to always jump to the top
		    if you trigger a link or button action that stays on the same page.
		    Default: "false"
		</description>
	</context-param>

    <!-- Extensions Filter -->
	<filter>
		<filter-name>extensionsFilter</filter-name>
		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
		<init-param>
			<param-name>uploadMaxFileSize</param-name>
			<param-value>100m</param-value>
			<description>
				Set the size limit for uploaded files.
				Format: 10 - 10 bytes
					10k - 10 KB
					10m - 10 MB
					1g - 1 GB
			</description>
		</init-param>
		<init-param>
			<param-name>uploadThresholdSize</param-name>
			<param-value>100k</param-value>
			<description>
				Set the threshold size - files below this limit are stored in memory, files above
				this limit are stored on disk.
	
				Format: 10 - 10 bytes
					10k - 10 KB
					10m - 10 MB
					1g - 1 GB
			</description>
		</init-param>
	</filter>

    <!-- ### Faces Servlet Mapping  #####################################################################
########################## -->
    
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.seam</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>

</web-app>

	




The portlet implementation of the FaceletsViewHandler
Code:

package com.sun.facelets;

import java.io.IOException;

import javax.faces.FacesException;
import javax.faces.application.ViewHandler;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.render.RenderKit;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

/**
 * ViewHandler implementation for Facelets used in Portlets
 * 
 */
public class FaceletPortletViewHandler extends FaceletViewHandler {
	 public FaceletPortletViewHandler(ViewHandler parent) {
	        super(parent);
	    }

	    protected ResponseWriter createResponseWriter(FacesContext context)
	            throws IOException, FacesException {
	        ExternalContext extContext = context.getExternalContext();
	        RenderKit renderKit = context.getRenderKit();

	        RenderRequest request = (RenderRequest) extContext.getRequest();
	        RenderResponse response = (RenderResponse) extContext.getResponse();

	        String contenttype = request.getResponseContentType();
	        if (contenttype == null) {
	            contenttype = "text/html";
	        }

	        String encoding = response.getCharacterEncoding();
	        if (encoding == null) {
	            encoding = "ISO-8859-1";
	        }

	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
coding);

	        contenttype = writer.getContentType();

	        // apply them to the response
	        response.setContentType(contenttype);

	        // Now, clone with the real writer
	        writer = writer.cloneWithWriter(response.getWriter());

	        return writer;
	    }

}

	



Special version of the MyFaceGenericPortlet.
Code:

/**
 * 
 */
package com.smies.portlet;

import java.io.IOException;
import java.util.Enumeration;

import javax.portlet.PortletException;
import javax.portlet.PortletMode;
import javax.portlet.PortletSession;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.UnavailableException;

/**
 * 
 */
public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {

	private String viewPage = null;
	private String editPage = null;
	private String helpPage = null;
	
	public void init() throws UnavailableException, PortletException {
		viewPage = (String) this.getInitParameter("ViewPage");
		editPage = (String) this.getInitParameter("EditPage");
		helpPage = (String) this.getInitParameter("HelpPage");
		super.init();
	}
	
	public void render(RenderRequest request, RenderResponse response)
			throws PortletException, IOException {

		PortletSession session = request.getPortletSession();
		PortletMode mode = (PortletMode) session
				.getAttribute("CurrentPortletMode");

		if (mode == null) {
			mode = request.getPortletMode();
		}

		if (mode != request.getPortletMode()) {
			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
		} else {
			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
		}

		session.setAttribute("CurrentPortletMode", mode);
		super.render(request, response);
	}
	
	protected void setDefaultView() throws UnavailableException {
        this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
        if (defaultView == null) {
        	this.defaultView = this.viewPage;
        }
        if (defaultView == null) {
            String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
            throw new UnavailableException(msg);
        }
    }

	protected void doEdit(RenderRequest request, RenderResponse response)
			throws PortletException, IOException {

		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
		if (isPortletModeChanged.booleanValue()) {
			setPortletRequestFlag(request);
			nonFacesRequest(request, response, editPage);
			return;
		}

		facesRender(request, response);
	}

	protected void doHelp(RenderRequest request, RenderResponse response)
			throws PortletException, IOException {

		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
		if (isPortletModeChanged.booleanValue()) {
			setPortletRequestFlag(request);
			nonFacesRequest(request, response, helpPage);
			return;
		}

		facesRender(request, response);
	}

}

	




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:57:30 2006
From: jira-events at jboss.com (Penkov Vladimir (JIRA))
Date: Thu, 7 Sep 2006 03:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-665) @PostConstruct
 throws NPE when EntityManager is used
In-Reply-To: <24188502.1153922291327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24586971.1157615850341.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-665?page=comments#action_12343001 ] 
            
Penkov Vladimir commented on EJBTHREE-665:
------------------------------------------

got the same problem

Fedora Core 5
jboss-4.0.4.GA-patch1 + EJB3.0-RC8

> @PostConstruct throws NPE when EntityManager is used
> ----------------------------------------------------
>
>                 Key: EJBTHREE-665
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-665
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: Windows XP, JBoss 4.0.4.GA + EJB-3.0-RC8
>            Reporter: Steven Verze
>
> @PostConstruct method throws NPE when called on a stateless session bean.
> The method iteself accesses the enetity manager and tries create a query, the following exception is experienced:
> java.lang.RuntimeException: java.lang.NullPointerException
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:109)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:163)
> 	at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:125)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceBean.initialiseSpendCardQuery(SnapAccountSendProcessServiceBean.java:83)
> 	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.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:159)
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:105)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
> 	at $Proxy3.getBatchNumbers(Unknown Source)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceTest.testGetBatchNumbers(SnapAccountSendProcessServiceTest.java:57)
> 	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 junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Here is a the post construct method:
> @PostConstruct
>     void initialiseSpendCardQuery()
> 	{		
> 		StringBuilder sendCardQueryString = new StringBuilder();    	
> 		sendCardQueryString.append("SELECT c FROM Card AS c WHERE c.status = 'U' AND c.batchNumber IN (");
> 		 
> 		long[] batchNumbers = getBatchNumbers();
> 		for (int i = 0; i < batchNumbers.length; i++)
> 		{
> 		    sendCardQueryString.append("?").append(i);
> 			if (i+1 < batchNumbers.length)
> 			    sendCardQueryString.append(",");
> 		}
> 		sendCardQueryString.append(") AND c NOT IN (SELECT lc.sendCard FROM SendCardLock AS lc)");
> 		sendCardQuery = entityManager.createQuery(sendCardQueryString.toString());
> 		 
> 		for (int i = 0; i < batchNumbers.length; i++)
> 			sendCardQuery.setParameter(i, batchNumbers[i]);		
> 	}
> It happens when the entityManager is used.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:13:30 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Thu, 7 Sep 2006 04:13:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-301) Group partition when
 processes start almost same time
Message-ID: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>

Group partition when processes start almost same time
-----------------------------------------------------

                 Key: JGRP-301
                 URL: http://jira.jboss.com/jira/browse/JGRP-301
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4
         Environment: Window XP
            Reporter: Sammi Ting
         Assigned To: Bela Ban
            Priority: Minor


There are 4 processes named A, B, C, D which should be join in a same group

Startup Sequence: A->B->C-D

Scenario:
1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
2. A join group with itself only (from log file on A, never see B, C, D)
3. B, C, D joined group together (from log files on B, C, D, never can see A)
4. Wait for long time A still in a single group


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:13:30 2006
From: jira-events at jboss.com (Stephen Friedrich (JIRA))
Date: Thu, 7 Sep 2006 04:13:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-265) Inject via method
	parameters
Message-ID: <25702530.1157616810813.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-265?page=comments#action_12343002 ] 
            
Stephen Friedrich commented on JBSEAM-265:
------------------------------------------

I don't grok this: At first I thought it's nice to use params instead of fields just to keep everything in as narrow scope as possible.
But who is going to call this method?
>From Java code I still need to pass an argument. If I do so, is it overriden by the context variable?
If, however I call this method from JSF expressions - well I could simply reference the user context variable in the call instead.

Probably I am missing the point...

> Inject via method parameters
> ----------------------------
>
>                 Key: JBSEAM-265
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-265
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>
> public void login(@In("user") User user) {
>    ...
> }
> is ugly, but we should support it anyway.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:25:26 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 04:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-301) Group partition
 when processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17811821.1157617526841.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-301?page=comments#action_12343003 ] 
            
Bela Ban commented on JGRP-301:
-------------------------------

Stack configuration ?
JGroups version ?

This is one of the most frequently tested scenarios (JGroups/doc/tests/GmsTests.txt), more likely it is a network issue. Next time, could you please discuss this on the mailing lists before opening a JIRA issue ?

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:25:26 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 04:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-301) Group partition when
 processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28672172.1157617526988.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-301?page=all ]

Bela Ban updated JGRP-301:
--------------------------

    Fix Version/s: 2.4

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:33:28 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Thu, 7 Sep 2006 04:33:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-746) replace
 NullPointerExceptions with JbpmExceptions
Message-ID: <24411573.1157618008353.JavaMail.jira@cloud.prod.atl2.jboss.com>

replace NullPointerExceptions with JbpmExceptions
-------------------------------------------------

                 Key: JBPM-746
                 URL: http://jira.jboss.com/jira/browse/JBPM-746
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:35:28 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Thu, 7 Sep 2006 04:35:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-746) replace
 NullPointerExceptions with JbpmExceptions
In-Reply-To: <24411573.1157618008353.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18884562.1157618128616.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-746?page=all ]

Tom Baeyens updated JBPM-746:
-----------------------------

    Description: replace the NPE's thrown by jbpm with JbpmExceptions.

> replace NullPointerExceptions with JbpmExceptions
> -------------------------------------------------
>
>                 Key: JBPM-746
>                 URL: http://jira.jboss.com/jira/browse/JBPM-746
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 1, jBPM 3.1.3
>
>
> replace the NPE's thrown by jbpm with JbpmExceptions.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:49:28 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Thu, 7 Sep 2006 04:49:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3630) JMSTransportSupport
 is not portable across different JMS providers.
Message-ID: <32915025.1157618968630.JavaMail.jira@cloud.prod.atl2.jboss.com>

JMSTransportSupport is not portable across different JMS providers.
-------------------------------------------------------------------

                 Key: JBAS-3630
                 URL: http://jira.jboss.com/jira/browse/JBAS-3630
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Darran Lofthouse
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.6.CR1


JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -

String fromName = null;
         Destination destination = message.getJMSDestination();
         if (destination instanceof Queue)
            fromName = "queue/" + ((Queue)destination).getQueueName();
         if (destination instanceof Topic)
            fromName = "topic/" + ((Topic)destination).getTopicName();

For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.

The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -

http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html

A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:51:27 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Thu, 7 Sep 2006 04:51:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3630) JMSTransportSupport
 is not portable across different JMS providers.
In-Reply-To: <32915025.1157618968630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12722656.1157619087585.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3630?page=all ]

Darran Lofthouse reassigned JBAS-3630:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Thomas Diesler)

> JMSTransportSupport is not portable across different JMS providers.
> -------------------------------------------------------------------
>
>                 Key: JBAS-3630
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3630
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
> String fromName = null;
>          Destination destination = message.getJMSDestination();
>          if (destination instanceof Queue)
>             fromName = "queue/" + ((Queue)destination).getQueueName();
>          if (destination instanceof Topic)
>             fromName = "topic/" + ((Topic)destination).getTopicName();
> For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
> The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
> http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
> A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:53:29 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Thu, 7 Sep 2006 04:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-301) Group partition
 when processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17307994.1157619209493.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-301?page=comments#action_12343004 ] 
            
Sammi Ting commented on JGRP-301:
---------------------------------

Version: 2.4CR1

All processes use same configuration:

<config>
    <TCP start_port="8000" loopback="true" send_buf_size="100000" recv_buf_size="200000" enable_diagnostics="false"/>
    <TCPPING timeout="3000" initial_hosts="localhost[8000]" port_range="4" num_initial_members="4"/>
    <FD timeout="2000" max_tries="4"/>
    <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
    <pbcast.NAKACK gc_lag="100" retransmit_timeout="600,1200,2400,4800"/>
    <pbcast.STABLE stability_delay="500" desired_avg_gossip="20000" down_thread="false" max_bytes="40000000" up_thread="false"/>
    <VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />
    <pbcast.GMS print_local_addr="true" join_timeout="5000" join_retry_timeout="2000" shun="true"/>
</config>

All processes are seperate JVM under same machine. I just open different consoles for testing failover and found there are group partitions.

I just know there is such forum in sourceforge. I will switch my focus to there see if solution right there.

Thanks.

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:59:28 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Thu, 7 Sep 2006 04:59:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3630) JMSTransportSupport
 is not portable across different JMS providers.
In-Reply-To: <32915025.1157618968630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11913830.1157619568540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3630?page=all ]

Darran Lofthouse updated JBAS-3630:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90134

> JMSTransportSupport is not portable across different JMS providers.
> -------------------------------------------------------------------
>
>                 Key: JBAS-3630
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3630
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
> String fromName = null;
>          Destination destination = message.getJMSDestination();
>          if (destination instanceof Queue)
>             fromName = "queue/" + ((Queue)destination).getQueueName();
>          if (destination instanceof Topic)
>             fromName = "topic/" + ((Topic)destination).getTopicName();
> For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
> The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
> http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
> A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:06:44 2006
From: jira-events at jboss.com (=?UTF-8?Q?Michael_Gr=C3=BCbsch_=28JIRA=29?=)
Date: Thu, 7 Sep 2006 07:06:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-699)
 StackOverflowError in
 org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy
Message-ID: <7825526.1157627204073.JavaMail.jira@cloud.prod.atl2.jboss.com>

StackOverflowError in org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy
-----------------------------------------------------------------------

                 Key: EJBTHREE-699
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-699
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC7 - FD
         Environment: Windows XP
            Reporter: Michael Gr?bsch
            Priority: Critical


I refer to source version $Revision: 1.1.4.2 $

This is an excerpt from the stack trace:

	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
	at $Proxy398.toString(Unknown Source)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
	at $Proxy398.toString(Unknown Source)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)

You may see, that invoke calls getProxyString which in turn on the proxy calls invoke!



-- 
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

       



From jira-events at jboss.com  Thu Sep  7 07:28:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 07:28:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3631) Missing branch in
 StdServerSession commit logic
Message-ID: <5722134.1157628523903.JavaMail.jira@cloud.prod.atl2.jboss.com>

Missing branch in StdServerSession commit logic
-----------------------------------------------

                 Key: JBAS-3631
                 URL: http://jira.jboss.com/jira/browse/JBAS-3631
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Weston Price
             Fix For: JBossAS-4.0.5.GA


There is a missing branch in the StdServerSession commit logic.

In the case where the transaction manager rollsback the transaction early,
e.g. JBossTM does this for transaction timeouts, the status will be NO_TRANSACTION
(or a heuristic state).

The code:

               // Marked rollback
               if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK)
               {
                  if (trace)
                     log.trace(StdServerSession.this + " rolling back JMS transaction tx=" + trans);
                  // actually roll it back
                  tm.rollback();

                  // NO XASession? then manually rollback.
                  // This is not so good but
                  // it's the best we can do if we have no XASession.
                  if (xaSession == null && serverSessionPool.isTransacted())
                  {
                     session.rollback();
                  }
               }
               else if (trans.getStatus() == Status.STATUS_ACTIVE)
               {
                  // Commit tx
                  // This will happen if
                  // a) everything goes well
                  // b) app. exception was thrown
                  if (trace)
                     log.trace(StdServerSession.this + " commiting the JMS transaction tx=" + trans);
                  tm.commit();

                  // NO XASession? then manually commit.  This is not so good but
                  // it's the best we can do if we have no XASession.
                  if (xaSession == null && serverSessionPool.isTransacted())
                  {
                     session.commit();
                  }
               }

needs an extra branch:

               else
               {
                  if (trace)
                     log.trace(StdServerSession.this + " transaction already ended tx=" + trans);
                  // spend the thread association
                  tm.suspend();

                  // NO XASession? then manually rollback.
                  // This is not so good but
                  // it's the best we can do if we have no XASession.
                  if (xaSession == null && serverSessionPool.isTransacted())
                  {
                     session.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

        


From jira-events at jboss.com  Thu Sep  7 07:28:44 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 07:28:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-464) move to maven for
	build system
In-Reply-To: <27270398.1156948664199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15547257.1157628524036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-464?page=all ]

Michael Neale resolved JBRULES-464.
-----------------------------------

    Resolution: Done

> move to maven for build system
> ------------------------------
>
>                 Key: JBRULES-464
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-464
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:30:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 07:30:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3632) Too early checking
 of not closing connections
Message-ID: <10803421.1157628643891.JavaMail.jira@cloud.prod.atl2.jboss.com>

Too early checking of not closing connections
---------------------------------------------

                 Key: JBAS-3632
                 URL: http://jira.jboss.com/jira/browse/JBAS-3632
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Weston Price
            Priority: Minor


In the case where a transaction is ended early,
e.g. JBossTM rollsback transactions at a timeout immediately,
the cached connection manager is firing connection not closed events.

This is because the ejb is still in the invocation with the connection open
but the transaction synchronization is fired by the rollback/timeout.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:34:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 07:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-477) BIG REFACTOR:
 rename nodes to
 not have underscores, and pull out jackrabbit deps from the main repository
 class (seperate configuration)
Message-ID: <21151814.1157628883910.JavaMail.jira@cloud.prod.atl2.jboss.com>

BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)
----------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-477
                 URL: http://jira.jboss.com/jira/browse/JBRULES-477
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: drools-brms
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:34:44 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 07:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-477) BIG REFACTOR:
 rename nodes to
 not have underscores, and pull out jackrabbit deps from the main repository
 class (seperate configuration)
In-Reply-To: <21151814.1157628883910.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14055226.1157628884030.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-477?page=all ]

Michael Neale resolved JBRULES-477.
-----------------------------------

    Resolution: Done

> BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-477
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-477
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:34:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 07:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3633) Tidyup logging when
 transaction is no longer active
Message-ID: <12054517.1157628884153.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tidyup logging when transaction is no longer active
---------------------------------------------------

                 Key: JBAS-3633
                 URL: http://jira.jboss.com/jira/browse/JBAS-3633
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JB5-Transaction Manager
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
            Priority: Minor


Since JBossTM rollsback transactions at transaction timeout,
we need to tidyup the transaction demarcation code (commit/rollback/setRollbackOnly, etc)
such that the logging is more information and not so noisy.

We still need to communicate that the transaction rolled back even if it is not
the transaction demarcation point that does the rollback.

Currrently, you get errors/warnings about not being able to setRollbackOnly or rollback,
because the transaction is already ended.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:52:44 2006
From: jira-events at jboss.com (cosmin c (JIRA))
Date: Thu, 7 Sep 2006 07:52:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <2293262.1157629964129.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12343008 ] 
            
cosmin c commented on EJBTHREE-402:
-----------------------------------

Hi, I want to do a JUnit Test and I have this problem too ....

avax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.remoting.IsLocalInterceptor;
    local class incompatible: stream classdesc serialVersionUID = -3758782076801249473, local class serialVersionUID = 595045557897063404]
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:722)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at com.nortel.emp.utils.DeviceProfileManagementTest.getInventory(DeviceProfileManagementTest.java:35)
	at com.nortel.emp.utils.DeviceProfileManagementTest.testLookupInventoryService(DeviceProfileManagementTest.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Caused by: java.io.InvalidClassException: org.jboss.ejb3.remoting.IsLocalInterceptor; local class incompatible: 
    stream classdesc serialVersionUID = -3758782076801249473, local class serialVersionUID = 595045557897063404
	at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
	at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
	at java.io.ObjectInputStream.readClassDesc(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.readArray(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
	at java.io.ObjectInputStream.readSerialData(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
	at java.io.ObjectInputStream.readSerialData(Unknown Source)
.......

It seems that I have different version of class org.jboss.ejb3.remoting.IsLocalInterceptor and this is right, but I have a problem when I tried to fix this one. This class apear in my repository in jboss-ejb3-client-4.0.4.jar and in jboss(jboss-ejb3 I have) in jboss-ejb3.jar. Those jars didn't match but if I change only the class IsLocalInterceptor from one to another the test will work, but I can di that, I have to find a better solution. I don't know exactly why I have an older version on jboss server because I have the last version on jboss-ejb3. 

Do you have any ideeas ....

Thanks.



> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 08:38:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 08:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3634) Acknowledgement of
 transacted message in MessageListener should be inside delivery lock
Message-ID: <4660406.1157632723860.JavaMail.jira@cloud.prod.atl2.jboss.com>

Acknowledgement of transacted message in MessageListener should be inside delivery lock
---------------------------------------------------------------------------------------

                 Key: JBAS-3634
                 URL: http://jira.jboss.com/jira/browse/JBAS-3634
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For: JBossAS-4.0.5.GA


The acknowledgement of a transacted message for a MessageListener
should be inside the delivery lock.

Otherwise the addition of the acknowledgement could be competing with other
operations on the session, e.g. commit/rollback/recover.

org.jboss.mq.SpyMessageConsumer::run()

+            // Try to obtain the session delivery lock
+           // This avoids concurrent delivery to message listeners in the same session as per spec
+            boolean gotDeliveryLock = false;
+            while (gotDeliveryLock == false)
+            {

            if (session.transacted)
            {
               // REVIEW: for an XASession without a transaction this will ack the message
               // before it has been processed. Plain message listeners
               // are not supported in a j2ee environment, but what if somebody is trying 
               // to be clever?
               if (trace)
                  log.trace("run() acknowledging message in tx mes=" + mes.getJMSMessageID() + " " + this); 
               session.connection.spyXAResourceManager.ackMessage(session.getCurrentTransactionId(), mes);
            }

-            // Try to obtain the session delivery lock
-            // This avoids concurrent delivery to message listeners in the same session as per spec
-            boolean gotDeliveryLock = false;
-            while (gotDeliveryLock == false)
-            {

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 08:52:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 08:52:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-301) Group partition
 when processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31958230.1157633563955.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-301?page=comments#action_12343013 ] 
            
Bela Ban commented on JGRP-301:
-------------------------------

Works for me, even startup of all 4 processes at the same time. I made 2 changes though:
- Added bind_addr="192.168.5.2" to TCP
- Changed initial_hosts="192.168.5.2[8000]" in TCPPING
- Reduced port_range in TCPPING to 2

I assume 'localhost' is not set to the right IP address in your config

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 08:52:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 08:52:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-301) Group partition when
 processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15505621.1157633564119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-301?page=all ]

Bela Ban resolved JGRP-301.
---------------------------

    Resolution: Cannot Reproduce Bug

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:32:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:32:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-337) language support
 for 'accumulate'
Message-ID: <9684539.1157635964113.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-337?page=all ]

Edson Tirelli reassigned JBRULES-337:
-------------------------------------

    Assignee: Edson Tirelli  (was: Michael Neale)

> language support for 'accumulate'
> ---------------------------------
>
>                 Key: JBRULES-337
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-337
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:32:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:32:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-217) Add 'accumulate'
 Conditional Element
Message-ID: <3528281.1157635964355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-217?page=all ]

Edson Tirelli reassigned JBRULES-217:
-------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Add 'accumulate' Conditional Element
> ------------------------------------
>
>                 Key: JBRULES-217
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-217
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>
> Add jess style accumulate functionality.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:48:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:48:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-336) core reteoo
 implementation for 'accumulate'
Message-ID: <533314.1157636924014.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-336?page=comments#action_12343016 ] 
            
Edson Tirelli commented on JBRULES-336:
---------------------------------------

Commited first version of running code into trunk in revision #6107:

----------------
* JBRULES-217: Adding Accumulate Conditional Element

  * JBRULES-336: Adding core support for Accumulate
    - Implemented AccumulateNode, Accumulate CE, Accumulator interface
    - Added support into ReteooBuilder
    - Added wiring support for generated code

  * JBRULES-337: Adding language support for Accumulate
    - Added grammar rules
    - Added parser support
    - Added AST classes
    - Added rule builder support
    - Added string templates for code generation

  * Added test cases for all classes

----------------
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParser.java
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParserLexer.java
Adding         drools-compiler/src/main/java/org/drools/lang/descr/AccumulateDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/ColumnDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/DescrFactory.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/FunctionBuilder.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/lang/drl.g
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/lang/RuleParserTest.java
Adding         drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate_with_bindings.drl
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrs
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrsPerson
Sending        drools-compiler/src/test/resources/org/drools/reteoo/ThreeColumnsWithConstraints
Sending        drools-core/src/main/java/org/drools/base/dataproviders/MethodDataProvider.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Deleting       drools-core/src/main/java/org/drools/reteoo/Accumulator.java
Deleting       drools-core/src/main/java/org/drools/reteoo/CalculatedObjectHandle.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteooBuilder.java
Adding         drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/rule/PackageCompilationData.java
Sending        drools-core/src/main/java/org/drools/rule/Rule.java
Adding         drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Replacing      drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data ..............................
Committed revision 6107.
------------------

Now, need to improve test scenarios and fix any eventual bug.


> core reteoo implementation for 'accumulate'
> -------------------------------------------
>
>                 Key: JBRULES-336
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-336
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:48:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:48:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-337) language support
 for 'accumulate'
Message-ID: <23165644.1157636924166.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-337?page=comments#action_12343017 ] 
            
Edson Tirelli commented on JBRULES-337:
---------------------------------------

Commited first version of running code into trunk in revision #6107:

----------------
* JBRULES-217: Adding Accumulate Conditional Element

  * JBRULES-336: Adding core support for Accumulate
    - Implemented AccumulateNode, Accumulate CE, Accumulator interface
    - Added support into ReteooBuilder
    - Added wiring support for generated code

  * JBRULES-337: Adding language support for Accumulate
    - Added grammar rules
    - Added parser support
    - Added AST classes
    - Added rule builder support
    - Added string templates for code generation

  * Added test cases for all classes

----------------
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParser.java
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParserLexer.java
Adding         drools-compiler/src/main/java/org/drools/lang/descr/AccumulateDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/ColumnDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/DescrFactory.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/FunctionBuilder.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/lang/drl.g
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/lang/RuleParserTest.java
Adding         drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate_with_bindings.drl
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrs
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrsPerson
Sending        drools-compiler/src/test/resources/org/drools/reteoo/ThreeColumnsWithConstraints
Sending        drools-core/src/main/java/org/drools/base/dataproviders/MethodDataProvider.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Deleting       drools-core/src/main/java/org/drools/reteoo/Accumulator.java
Deleting       drools-core/src/main/java/org/drools/reteoo/CalculatedObjectHandle.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteooBuilder.java
Adding         drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/rule/PackageCompilationData.java
Sending        drools-core/src/main/java/org/drools/rule/Rule.java
Adding         drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Replacing      drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data ..............................
Committed revision 6107.
------------------

Now, need to improve test scenarios and fix any eventual bug.


> language support for 'accumulate'
> ---------------------------------
>
>                 Key: JBRULES-337
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-337
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:06:46 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 7 Sep 2006 10:06:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-619) PojoCache to
 support JDK5.0 Enum
Message-ID: <27958706.1157638006529.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-619?page=comments#action_12343019 ] 
            
Ben Wang commented on JBCACHE-619:
----------------------------------

No, ejb3 entity cache doesn't use PojoCache. It uses the regular TreeCache, rather. So it should not be an issue there.

> PojoCache to support JDK5.0 Enum
> --------------------------------
>
>                 Key: JBCACHE-619
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-619
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:27:28 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 10:27:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-478) eclipse plugin
 support for 'accumulate'
Message-ID: <10605990.1157639248991.JavaMail.jira@cloud.prod.atl2.jboss.com>

eclipse plugin support for 'accumulate'
---------------------------------------

                 Key: JBRULES-478
                 URL: http://jira.jboss.com/jira/browse/JBRULES-478
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Kris Verlaenen




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:31:31 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 10:31:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-478) eclipse plugin
 support for 'accumulate'
In-Reply-To: <10605990.1157639248991.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27735354.1157639491531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-478?page=all ]

Edson Tirelli updated JBRULES-478:
----------------------------------

      Component/s: Eclipse IDE
    Fix Version/s: 3.1-m1
      Description: 
Kris, 

We need to add support to 'accumulate' in the Eclipse plugin. I'm still testing the more complex functionality, but the basics are there (commited to trunk in revision #6107), so I guess you are free to work your side when you have the time. 

There is an integration test you can use: test_Accumulate.drl.

Let me know if you have any question. 

Thanks,
Edson

> eclipse plugin support for 'accumulate'
> ---------------------------------------
>
>                 Key: JBRULES-478
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-478
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Edson Tirelli
>         Assigned To: Kris Verlaenen
>             Fix For: 3.1-m1
>
>
> Kris, 
> We need to add support to 'accumulate' in the Eclipse plugin. I'm still testing the more complex functionality, but the basics are there (commited to trunk in revision #6107), so I guess you are free to work your side when you have the time. 
> There is an integration test you can use: test_Accumulate.drl.
> Let me know if you have any question. 
> Thanks,
> Edson

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:41:31 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 10:41:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-479) Wizard for
 autopopulating a decision table
Message-ID: <667045.1157640091287.JavaMail.jira@cloud.prod.atl2.jboss.com>

Wizard for autopopulating a decision table
------------------------------------------

                 Key: JBRULES-479
                 URL: http://jira.jboss.com/jira/browse/JBRULES-479
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Michael Neale
         Assigned To: Mark Proctor
            Priority: Minor


This could be done quite easily by a contributor.

Have a wizard (in the IDE) which takes information regarding the facts to be used, fields, actions (and the number of each) and generates a decision table based on that info capture (ie populates it).

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:43:33 2006
From: jira-events at jboss.com (Sam Healy (JIRA))
Date: Thu, 7 Sep 2006 10:43:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-747) Add configuration
 type of "normal"
 or "default" to the gpd action handler configuration dialog
Message-ID: <12536108.1157640213142.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add configuration type of "normal" or "default" to the gpd action handler configuration dialog
----------------------------------------------------------------------------------------------

                 Key: JBPM-747
                 URL: http://jira.jboss.com/jira/browse/JBPM-747
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Graphical Process Designer
    Affects Versions:  jBPM 3.1.2
         Environment: Win XP Pro, Eclipse 3.1.2
            Reporter: Sam Healy
         Assigned To: Tom Baeyens


When configuring action handlers on nodes using the gpd, no option is provided in the configuration window to use a configuration type of "default" or "normal" where a simple instantiation of the action class would suffice. As it is now, the implication is that an action class of this nature cannot be used. 

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 11:20:31 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Thu, 7 Sep 2006 11:20:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-362) NPE from
 org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
Message-ID: <24905392.1157642431741.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE from org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
-----------------------------------------------------------------------------------

                 Key: JBIDE-362
                 URL: http://jira.jboss.com/jira/browse/JBIDE-362
             Project: JBoss IDE
          Issue Type: Bug
          Components: JBossAS Adapter
    Affects Versions: 2.0.0.Beta1
            Reporter: Darryl Miles
         Assigned To: Robert Stryker


Just thought I'd report this.

java.lang.NullPointerException
at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports(ArchiveModuleFactory.java:64)
at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.acceptAddition(ArchiveModuleFactory.java:33)
at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory$1.visit(JBossModuleFactory.java:88)
at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:105)
at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:103)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:87)
at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.cacheModules(JBossModuleFactory.java:86)
at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.getModules(JBossModuleFactory.java:66)
at org.eclipse.wst.server.core.internal.ModuleFactory.getModules(ModuleFactory.java:133)
at org.eclipse.wst.server.core.ServerUtil.getModules(ServerUtil.java:285)
at org.eclipse.wst.server.core.ServerUtil.getModule(ServerUtil.java:52)
at org.eclipse.wst.web.internal.deployables.ComponentDeployable.gatherModuleReference(ComponentDeployable.java:126)
at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.gatherModuleReference(J2EEFlexProjDeployable.java:466)
at org.eclipse.wst.web.internal.deployables.ComponentDeployable.getModules(ComponentDeployable.java:113)
at org.eclipse.jst.server.tomcat.core.internal.TomcatServer.getChildModules(TomcatServer.java:212)
at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2174)
at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:2334)
at org.eclipse.wst.server.core.internal.Server.visit(Server.java:2315)
at org.eclipse.wst.server.core.internal.Server.shouldRestart(Server.java:805)
at org.eclipse.wst.server.ui.internal.view.servers.ServerTableLabelProvider.getColumnText(ServerTableLabelProvider.java:183)
at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:309)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:95)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:843)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:849)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:465)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:843)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1955)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:753)
at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
at org.eclipse.wst.server.ui.internal.view.servers.ServerTableViewer.<init>(ServerTableViewer.java:240)
at org.eclipse.wst.server.ui.internal.view.servers.ServersView.createPartControl(ServersView.java:89)
at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:290)
at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:525)
at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:140)
at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268)
at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:394)
at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1144)
at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:620)
at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:532)
at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:562)
at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:244)
at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:815)
at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3284)
at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:957)
at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:941)
at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3408)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3406)
at org.eclipse.ui.internal.PerspectiveBarContributionItem.select(PerspectiveBarContributionItem.java:123)
at org.eclipse.ui.internal.PerspectiveBarContributionItem$1.widgetSelected(PerspectiveBarContributionItem.java:92)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3166)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2842)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
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:336)
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 11:22:44 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Thu, 7 Sep 2006 11:22:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-362) NPE from
 org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
In-Reply-To: <24905392.1157642431741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3711645.1157642564561.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-362?page=comments#action_12343023 ] 
            
Darryl Miles commented on JBIDE-362:
------------------------------------

Hmm... the version of the plugin code is this:

eclipse/plugins/org.jboss.ide.eclipse.as.core_1.0.0.Beta1/jbossascore.jar

Even thought I put 2.0.0.Beta1.

> NPE from org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
> -----------------------------------------------------------------------------------
>
>                 Key: JBIDE-362
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-362
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Robert Stryker
>
> Just thought I'd report this.
> java.lang.NullPointerException
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports(ArchiveModuleFactory.java:64)
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.acceptAddition(ArchiveModuleFactory.java:33)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory$1.visit(JBossModuleFactory.java:88)
> at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:105)
> at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
> at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:103)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:87)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.cacheModules(JBossModuleFactory.java:86)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.getModules(JBossModuleFactory.java:66)
> at org.eclipse.wst.server.core.internal.ModuleFactory.getModules(ModuleFactory.java:133)
> at org.eclipse.wst.server.core.ServerUtil.getModules(ServerUtil.java:285)
> at org.eclipse.wst.server.core.ServerUtil.getModule(ServerUtil.java:52)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.gatherModuleReference(ComponentDeployable.java:126)
> at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.gatherModuleReference(J2EEFlexProjDeployable.java:466)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.getModules(ComponentDeployable.java:113)
> at org.eclipse.jst.server.tomcat.core.internal.TomcatServer.getChildModules(TomcatServer.java:212)
> at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2174)
> at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:2334)
> at org.eclipse.wst.server.core.internal.Server.visit(Server.java:2315)
> at org.eclipse.wst.server.core.internal.Server.shouldRestart(Server.java:805)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableLabelProvider.getColumnText(ServerTableLabelProvider.java:183)
> at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:309)
> at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:95)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:849)
> at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:465)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1955)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:753)
> at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
> at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
> at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
> at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
> at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
> at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
> at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableViewer.<init>(ServerTableViewer.java:240)
> at org.eclipse.wst.server.ui.internal.view.servers.ServersView.createPartControl(ServersView.java:89)
> at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
> at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
> at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
> at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:290)
> at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:525)
> at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:140)
> at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268)
> at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
> at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:394)
> at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1144)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:620)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:532)
> at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:562)
> at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:244)
> at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:815)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3284)
> at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:957)
> at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:941)
> at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3408)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3406)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem.select(PerspectiveBarContributionItem.java:123)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem$1.widgetSelected(PerspectiveBarContributionItem.java:92)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3166)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2842)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
> 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:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:07:44 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 7 Sep 2006 12:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-760)
 TreeCacheListener in
 PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27865978.1157645264317.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=comments#action_12343027 ] 
            
Ben Wang commented on JBCACHE-760:
----------------------------------

Can you verify that this is also a problem with regular pojo? I'd think getObject in nodeModify will run into the same problem.

On a separate node, I am switching to pojo-based event listening. So this will not be a problem anymore in 2.0 release.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:09:43 2006
From: jira-events at jboss.com (Manfred Moser (JIRA))
Date: Thu, 7 Sep 2006 12:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8451088.1157645383709.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=comments#action_12343028 ] 
            
Manfred Moser commented on JBSEAM-340:
--------------------------------------

It is great that specifiying the resource bundle actually works however it is a bit counter intuitive when developing. You have to have it in the EJBs but you dont have to have it in other seam components. This should maybe be streamlined. At least there should be an example in the actual distro. And yes .. I agree that the hibnerate like variables should work too. In fact my entity unit tests test the validation with the hibernate validator assuming it would work in Seam. 



> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Thu Sep  7 12:15:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Thu, 7 Sep 2006 12:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1967635.1157645743816.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Nitzan Niv updated JBCACHE-760:
-------------------------------

    Attachment: TreeCacheAopListenerTest.java

tests for events on a PojoCache

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:17:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Thu, 7 Sep 2006 12:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-760)
 TreeCacheListener in
 PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11799140.1157645863838.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=comments#action_12343030 ] 
            
Nitzan Niv commented on JBCACHE-760:
------------------------------------

It does not happen on a non-collection object, only on collections. See attached tests.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:26:30 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Thu, 7 Sep 2006 12:26:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-289) Make service
 container configurable wrt datasource and persistence manager config
Message-ID: <19049348.1157646390609.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-289?page=comments#action_12343032 ] 
            
Tim Fox commented on JBMESSAGING-289:
-------------------------------------

We also need to make sure that when creating a PostOffice or any other component that requires sqlProperties the correct properties, in a core test, the correct properties are configured.
Currently this is not the case.

> Make service container configurable wrt datasource and persistence manager config
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-289
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-289
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>
> Must be made configurable so test suite can be run against different databases with different pm configs

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:36:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 12:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1024) Verify theme CSS
 compatible with multiple browsers/OS
Message-ID: <12922402.1157647004240.JavaMail.jira@cloud.prod.atl2.jboss.com>

Verify theme CSS compatible with multiple browsers/OS
-----------------------------------------------------

                 Key: JBPORTAL-1024
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1024
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:36:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 12:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1025) Integrate new
 theme with portal codebase
Message-ID: <22595979.1157647004438.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate new theme with portal codebase
----------------------------------------

                 Key: JBPORTAL-1025
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1025
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 13:35:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 7 Sep 2006 13:35:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-700) add ability to add
 descriptions to jmx operations in Service beans
Message-ID: <916539.1157650544830.JavaMail.jira@cloud.prod.atl2.jboss.com>

add ability to add descriptions to jmx operations in Service beans
------------------------------------------------------------------

                 Key: EJBTHREE-700
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-700
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC8 - FD
            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

        


From jira-events at jboss.com  Thu Sep  7 14:08:40 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 14:08:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-300) NAKACK.send()
 doesn't need to be synchronized
In-Reply-To: <9351729.1157614648499.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <720114.1157652520054.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-300?page=all ]

Bela Ban resolved JGRP-300.
---------------------------

    Resolution: Done

> NAKACK.send() doesn't need to be synchronized
> ---------------------------------------------
>
>                 Key: JGRP-300
>                 URL: http://jira.jboss.com/jira/browse/JGRP-300
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> NAKACK.send() currently calls passDown(evt) in a synchronized(sent_msgs) statement. However, this is not necessary (contrary to handleMessage() which needs to pass messages up in the order of sequence numbers) because messages can be sent un-ordered. The receivers will order the messages anyway, so if we sent 1,3,2,4 due to thread premption, the receivers will order them and deliver them as 1,2,3,4.
> BENEFIT: the less synchronization, the less probability of deadlocks

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:01:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 15:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1026) Fix Tabs CSS to
 work with existing Navigation CSS
Message-ID: <9596533.1157655703858.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix Tabs CSS to work with existing Navigation CSS
-------------------------------------------------

                 Key: JBPORTAL-1026
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1026
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:01:43 2006
From: jira-events at jboss.com (Ole Matzura (JIRA))
Date: Thu, 7 Sep 2006 15:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-350) create
 specification for jbossws/jbosside plugin / integration
In-Reply-To: <30880297.1155172032601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23282358.1157655703989.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-350?page=comments#action_12343043 ] 
            
Ole Matzura commented on JBIDE-350:
-----------------------------------

I agree.. there seems to be an infrastructure for this (see http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.wst.doc.isv/html/plugin_descriptions_WST/ws.html), but I cant find much documentation.. I'll download the WTP sources and have a look.. ;-)



> create specification for jbossws/jbosside plugin / integration
> --------------------------------------------------------------
>
>                 Key: JBIDE-350
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-350
>             Project: JBoss IDE
>          Issue Type: Task
>          Components: Webservices Plugin
>            Reporter: Ole Matzura
>         Assigned To: Ole Matzura
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossWS Eclipse Plugin Specification.doc
>
>
> we need a spec that outlines how jbossws should be integrated into eclipse/jbosside

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:07:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 15:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1027) New Renderer for
	New UI
Message-ID: <24226605.1157656063859.JavaMail.jira@cloud.prod.atl2.jboss.com>

New Renderer for New UI
-----------------------

                 Key: JBPORTAL-1027
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1027
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


Develop new Renderer class for new layout/theme.

The new usability requires additional functionality, that requires a new renderer:
1. New icon placement: ie, the remove window icon.
2. New region for Adding Content to a page.

Issues: New renderer will not be compatible with previous themes/layouts.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:11:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 15:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1028) Modify
 navigationportlet for scope-colored tabbing
Message-ID: <16685103.1157656303867.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify navigationportlet for scope-colored tabbing
--------------------------------------------------

                 Key: JBPORTAL-1028
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1028
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:19:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 7 Sep 2006 15:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-701) different
 interceptor stack
 for same method based on call via remote or local interface
Message-ID: <9781897.1157656783817.JavaMail.jira@cloud.prod.atl2.jboss.com>

different interceptor stack for same method based on call via remote or local interface
---------------------------------------------------------------------------------------

                 Key: EJBTHREE-701
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-701
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: William DeCoste
         Assigned To: William DeCoste
            Priority: Optional




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 19:55:26 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 19:55:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-327) Relax required=true
 in @Create and @Destroy methods
In-Reply-To: <10704879.1154964012187.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <77824.1157673326949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-327?page=all ]

Gavin King updated JBSEAM-327:
------------------------------

    Comment: was deleted

> Relax required=true in @Create and @Destroy methods
> ---------------------------------------------------
>
>                 Key: JBSEAM-327
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-327
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Might be convenient to relax required=true during lifecycle callbacks (but don't forget the EJB3 callbacks @PostCostruct/@PreDestroy/@PrePassivate/@PostActivate)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 19:57:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 19:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-338) Changes to
 SeamInterceptor break non-JSF calls.
In-Reply-To: <8417461.1156344946502.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13576981.1157673447143.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-338?page=comments#action_12343048 ] 
            
Gavin King commented on JBSEAM-338:
-----------------------------------

Note that this also occurs for finalizers.

> Changes to SeamInterceptor break non-JSF calls.
> -----------------------------------------------
>
>                 Key: JBSEAM-338
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-338
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>
> The CVS changes to SeamInterceptor have it call Component.forName() outside of the Seam contexts when called via MDB or RMI. Need to call beginCall(), endCall() from the @PostConstruct and @PostActivate methods.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:15:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:15:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-327) Relax required=true
 in @Create and @Destroy methods
In-Reply-To: <10704879.1154964012187.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9388449.1157674527330.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-327?page=all ]

Gavin King closed JBSEAM-327.
-----------------------------

    Resolution: Done

done

> Relax required=true in @Create and @Destroy methods
> ---------------------------------------------------
>
>                 Key: JBSEAM-327
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-327
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Might be convenient to relax required=true during lifecycle callbacks (but don't forget the EJB3 callbacks @PostCostruct/@PreDestroy/@PrePassivate/@PostActivate)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:17:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:17:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-338) Changes to
 SeamInterceptor break non-JSF calls.
In-Reply-To: <8417461.1156344946502.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11099714.1157674647478.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-338?page=all ]

Gavin King updated JBSEAM-338:
------------------------------

    Comment: was deleted

> Changes to SeamInterceptor break non-JSF calls.
> -----------------------------------------------
>
>                 Key: JBSEAM-338
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-338
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>
> The CVS changes to SeamInterceptor have it call Component.forName() outside of the Seam contexts when called via MDB or RMI. Need to call beginCall(), endCall() from the @PostConstruct and @PostActivate methods.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:19:29 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17320746.1157674769148.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=all ]

Gavin King closed JBSEAM-342.
-----------------------------

    Resolution: Won't Fix

We do not support nonstandard features of MyFaces.

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:21:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-344) Portal booking
 example loses conversation after validation error
In-Reply-To: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6515142.1157674887476.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-344?page=comments#action_12343051 ] 
            
Gavin King commented on JBSEAM-344:
-----------------------------------

This is probably due to a (fixed) known bug in that version of JBoss Portal where render parameters were "lost" by the portal.

> Portal booking example loses conversation after validation error
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-344
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Portal
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4.GA
> JBoss Portal 2.4.0-Beta1
> (used jems-installer-1.2.0.BETA)
> JBoss Seam 1.0.1.GA
>            Reporter: Mauro Lopez
>
> Followed this steps:
> - deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
> - Entered http://localhost:8080/portal
> - Selected the SeamHibernate portlet tab, registered user, logged in...
> - Searched hotels, selected one of them, and pressed the "Book" button.
> In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 
> So, after a failed validation, the conversation is lost.
> In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:21:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-346) Full <ejb-jar>
 declaration in examples' ejb-jar.xml files
In-Reply-To: <27019148.1157613568758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3335927.1157674887861.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-346?page=all ]

Gavin King closed JBSEAM-346.
-----------------------------

    Resolution: Duplicate Issue

dupe

> Full <ejb-jar> declaration in examples' ejb-jar.xml files
> ---------------------------------------------------------
>
>                 Key: JBSEAM-346
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-346
>             Project: JBoss Seam
>          Issue Type: Task
>          Components: Examples
>    Affects Versions: 1.0.1
>            Reporter: Stephen Friedrich
>
> Currently ejb-jar.xml files in seam examples (1.0.1 GA) use just "<ejb-jar>".
> Would be nicer if they used a full, standard compliant declaration:
> {code}
> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
>          version="3.0">	
> {code}

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:23:28 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:23:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-336) BigDecimal is not
 handled properly
In-Reply-To: <31483451.1155912041653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3479140.1157675008777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-336?page=all ]

Gavin King closed JBSEAM-336.
-----------------------------

    Resolution: Won't Fix

Not an issue in Seam. Hibernate Tools, if anything.

> BigDecimal is not handled properly
> ----------------------------------
>
>                 Key: JBSEAM-336
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-336
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: German or US locale, Windows XP Pro, myfaces 1.1.3, Oracle 9.2 or MySQL 4.1.9 
>            Reporter: Valerij Timofeev
>
> Generating CRUD Seam applications results in some fields having Java type BigDecimal.
> It seems that this type is not handled properly.
> There are no error messages in the JBoss server.log (log4j javax.faces & org.jboss.seam priorities are DEBUG). Query returns no results.
> Debugging shows for example that findFirstPage() method is never called.
> Changing type e.g. to Double fixes the issue (see workarounds for details) : it becomes possible to step through the method. And query returns some results.
> Clicking on create link and then switching to find view (other bean than current) results in the following JSF error:
> Cannot set value for expression '#{somebeanEditor.instance.id}' to a new value of type java.lang.String
> Where ID is of type BigDecimal.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:27:26 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:27:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2221777.1157675246297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=all ]

Gavin King reassigned JBSEAM-340:
---------------------------------

    Assignee: Emmanuel Bernard

> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>         Assigned To: Emmanuel Bernard
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Thu Sep  7 22:03:27 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Thu, 7 Sep 2006 22:03:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12286997.1157681007691.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12343055 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

Nice support guys thanks.

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 22:03:27 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Thu, 7 Sep 2006 22:03:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3139706.1157681007828.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12343056 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

You just need to support JSF spec well.

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From c10 at fullmailmarket.com  Thu Sep  7 23:31:20 2006
From: c10 at fullmailmarket.com (Facultad Economía y Negocio U. de Chile)
Date: Thu, 7 Sep 2006 23:31:20 -0400
Subject: [jboss-jira] =?iso-8859-1?q?Diplomado_Gesti=F3n_Integrada_-_La_S?=
	=?iso-8859-1?q?erena?=
Message-ID: <200609080331.k883VKgH026687@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060907/9a4b2ced/attachment.html 

From jira-events at jboss.com  Thu Sep  7 23:38:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 7 Sep 2006 23:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-424) Cannot access
 the first message when starting the JMS subscriber
Message-ID: <18420198.1157686723975.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-424?page=all ]

Clebert Suconic closed JBMESSAGING-424.
---------------------------------------

    Resolution: Duplicate Issue

This issue was fixed as a duplicate.

However I double checked this by creating another testcase

> Cannot access the first message when starting the JMS subscriber
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-424
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-424
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: JBoss jboss-4.0.4.GA & jboss-messaging-1.0.1.CR2 
>            Reporter: Seung Hyun
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>
> Some messages are already published to the specific queue and the queue contains few messages. Starts the subscriber to receive the messages in the queue. It reads all the messages except the first message. Also, the first message is not accessible at all.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 23:40:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 7 Sep 2006 23:40:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
Message-ID: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>

Crash Test failure on Durable Subscriber
----------------------------------------

                 Key: JBMESSAGING-541
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.0.1.CR5, 1.2.0.Alpha1


DurableSubscriberCrashTest1 and 2 are failing.
The routine that verifies if a connection is broken is only called upon communication exceptions. 

If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 04:55:31 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 04:55:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-348) IssueTracker
 example uses nonexisting annotation (Within)
Message-ID: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>

IssueTracker example uses nonexisting annotation (Within)
---------------------------------------------------------

                 Key: JBSEAM-348
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
             Project: JBoss Seam
          Issue Type: Bug
          Components: Examples
            Reporter: Stephan Bublava
            Priority: Trivial


org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Fri Sep  8 04:57:33 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 04:57:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-349) IssueTracker
 @LoggedIn missing @Interceptors annotation
Message-ID: <931519.1157705853664.JavaMail.jira@cloud.prod.atl2.jboss.com>

IssueTracker @LoggedIn missing @Interceptors annotation
-------------------------------------------------------

                 Key: JBSEAM-349
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-349
             Project: JBoss Seam
          Issue Type: Bug
          Components: Examples
            Reporter: Stephan Bublava
            Priority: Trivial


I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 05:03:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 8 Sep 2006 05:03:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-748) check variable
 hibernatability before serializability
Message-ID: <10629469.1157706212979.JavaMail.jira@cloud.prod.atl2.jboss.com>

check variable hibernatability before serializability
-----------------------------------------------------

                 Key: JBPM-748
                 URL: http://jira.jboss.com/jira/browse/JBPM-748
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1


when a variable is persisted, the order in which serializability and hibernatability is checked should be reversed.    the new behaviour should be that first hibernatability is checked and only afterwards, serializability should be checked.

see also: http://blogs.sourceallies.com/roller/page/joedeveloper?entry=jbpm_3_1_auto_user

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 05:07:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 8 Sep 2006 05:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-748) check variable
 hibernatability before serializability
In-Reply-To: <10629469.1157706212979.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1495723.1157706452319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-748?page=all ]

Tom Baeyens closed JBPM-748.
----------------------------

    Resolution: Done

> check variable hibernatability before serializability
> -----------------------------------------------------
>
>                 Key: JBPM-748
>                 URL: http://jira.jboss.com/jira/browse/JBPM-748
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1
>
>
> when a variable is persisted, the order in which serializability and hibernatability is checked should be reversed.    the new behaviour should be that first hibernatability is checked and only afterwards, serializability should be checked.
> see also: http://blogs.sourceallies.com/roller/page/joedeveloper?entry=jbpm_3_1_auto_user

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:17:30 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:17:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-363) Switch mode dialog
 asks for
 restart server if necessary, but restarts the server innecessary even when
 server is already in Debug mode
Message-ID: <21059668.1157721450807.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch mode dialog asks for restart server if necessary, but restarts the server innecessary even when server is already in Debug mode
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBIDE-363
                 URL: http://jira.jboss.com/jira/browse/JBIDE-363
             Project: JBoss IDE
          Issue Type: Bug
    Affects Versions: 2.0.0.Beta1
         Environment: Windows 2003 Server
jdk1.5.0_06
JBoss-4.0.4.GA
eclipse-M20060823

            Reporter: Johans Marvin Taboada Villca


When deploying (new) module (Degug as -> Debug On Server), wizard show information dialog asking to switch 
mode. Apparently isn't aware that server is already in debug mode. In any case it suggest 'Switch mode (will 
restart if necessary)', but this always restarts the server. One can avoid this bug by choosing 'Continue in the 
current mode' instead.


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:29:29 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-364) Secured JBoss server
 configured via 'JBoss Server View' fail to Start/Debug
Message-ID: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>

Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
---------------------------------------------------------------------------

                 Key: JBIDE-364
                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
             Project: JBoss IDE
          Issue Type: Bug
          Components: JBossAS Adapter
    Affects Versions: 2.0.0.Beta1
         Environment: Windows Server 2003
eclipse-M20060823-1200
JBoss-4.0.4.GA
jdk1.5.0_06
MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
jmx-console also secured with the same security Domain.

            Reporter: Johans Marvin Taboada Villca
         Assigned To: Robert Stryker


Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
- MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
   <descriptors>
      <interceptors>
         <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
            securityDomain="java:/jaas/jmx-console"/>
      </interceptors>
   </descriptors>
Im assuming that the 'jmx-console' is also secured with the same security Domain.
Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
on the server.


-- 
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

       



From jira-events at jboss.com  Fri Sep  8 09:43:29 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 8 Sep 2006 09:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-466) refactor
 RulesRepository to be injected JCR repository
In-Reply-To: <5779102.1157012983858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15270793.1157723009768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-466?page=all ]

Michael Neale resolved JBRULES-466.
-----------------------------------

    Resolution: Done

> refactor RulesRepository to be injected JCR repository
> ------------------------------------------------------
>
>                 Key: JBRULES-466
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-466
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> this is so in a container, it can come from JNDI etc... and test can use transient repository 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

        


From jira-events at jboss.com  Fri Sep  8 09:45:27 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:45:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-364) Secured JBoss
 server configured via 'JBoss Server View' fail to Start/Debug
In-Reply-To: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8709209.1157723127384.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-364?page=comments#action_12343067 ] 
            
Johans Marvin Taboada Villca commented on JBIDE-364:
----------------------------------------------------

>From the JBoss 'Server Editor' there's a link 'Edit' that is supposed to edit Runtime preferences, that's the right place to enter admin credentials for the JBossAdmin role, but its not working (at leats for me). Launch configuration is working fine.

> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-364
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200
> JBoss-4.0.4.GA
> jdk1.5.0_06
> MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
> jmx-console also secured with the same security Domain.
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>
> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
> - MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
> has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
>    <descriptors>
>       <interceptors>
>          <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
>             securityDomain="java:/jaas/jmx-console"/>
>       </interceptors>
>    </descriptors>
> Im assuming that the 'jmx-console' is also secured with the same security Domain.
> Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
> on the server.

-- 
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

       



From jira-events at jboss.com  Fri Sep  8 09:51:29 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 8 Sep 2006 09:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-412) Create web app
 component infrastructure
In-Reply-To: <2895546.1155288372585.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25393510.1157723489774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-412?page=all ]

Michael Neale resolved JBRULES-412.
-----------------------------------

    Resolution: Done

> Create web app component infrastructure
> ---------------------------------------
>
>                 Key: JBRULES-412
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-412
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Using Seam, or otherwise, need a "back end" web component framework which will work with the GWT generated UI, and use the drools-repository api.
> This task is just to setup the initial skeleton for development

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:55:29 2006
From: jira-events at jboss.com (Mauro Lopez (JIRA))
Date: Fri, 8 Sep 2006 09:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-344) Portal booking
 example loses conversation after validation error
In-Reply-To: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22238454.1157723729689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-344?page=all ]

Mauro Lopez updated JBSEAM-344:
-------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90229

> Portal booking example loses conversation after validation error
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-344
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Portal
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4.GA
> JBoss Portal 2.4.0-Beta1
> (used jems-installer-1.2.0.BETA)
> JBoss Seam 1.0.1.GA
>            Reporter: Mauro Lopez
>
> Followed this steps:
> - deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
> - Entered http://localhost:8080/portal
> - Selected the SeamHibernate portlet tab, registered user, logged in...
> - Searched hotels, selected one of them, and pressed the "Book" button.
> In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 
> So, after a failed validation, the conversation is lost.
> In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:57:29 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-365) Changing hostname in
 server
 config (JBoss 'Server Editor'), breaks twiddle monitoring for server
 startup
Message-ID: <24852255.1157723849263.JavaMail.jira@cloud.prod.atl2.jboss.com>

Changing hostname in server config (JBoss 'Server Editor'), breaks twiddle monitoring for server startup
--------------------------------------------------------------------------------------------------------

                 Key: JBIDE-365
                 URL: http://jira.jboss.com/jira/browse/JBIDE-365
             Project: JBoss IDE
          Issue Type: Bug
          Components: JBossAS Adapter
    Affects Versions: 2.0.0.Beta1
         Environment: Windows Server 2003
eclipse-M20060823-1200 (eclipse 3.2)
JBoss-4.0.4.GA
jdk1.5.0_06
            Reporter: Johans Marvin Taboada Villca
         Assigned To: Robert Stryker


Changing hostname in server config view breaks twiddle monitoring for server startup
Posible cause, maybe JBossIDE (?JBossAS Adapter?) access to twiddle script doesn't use yet
$WORKSPACE\.metadata\.plugins\org.eclipse.wst.server.core\servers.xml
to set -s option on the twiddle script.
Also, changing hostname doesn't change Launch configuration, where argument '--host=localhost' is set by default.
file: $WORKSPACE\.metadata\.plugins\org.eclipse.debug.core\.launches\JBoss-4.0.4.GA.launch


-- 
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

       



From jira-events at jboss.com  Fri Sep  8 10:11:33 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 10:11:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-366) Renaming Server Name
 (Host name) twice, pops up an error dialog
Message-ID: <3913669.1157724693540.JavaMail.jira@cloud.prod.atl2.jboss.com>

Renaming Server Name (Host name) twice, pops up an error dialog
---------------------------------------------------------------

                 Key: JBIDE-366
                 URL: http://jira.jboss.com/jira/browse/JBIDE-366
             Project: JBoss IDE
          Issue Type: Bug
    Affects Versions: 2.0.0.Beta1
         Environment: Windows Server 2003
eclipse-M20060823-1200 (eclipse 3.2)
JBoss-4.0.4.GA
jdk1.5.0_06

            Reporter: Johans Marvin Taboada Villca


Renaming Server Name (Host name) twice in the JBoss 'Server Editor', pops up an error dialog:
'Error while saving. Could not save because the file has been modified since the start of editting'
Once someone has change it and save it, must close the editor and reopen it, if needs to rename it again.


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 10:53:28 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 8 Sep 2006 10:53:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-477) BIG REFACTOR:
 rename nodes to
 not have underscores, and pull out jackrabbit deps from the main repository
 class (seperate configuration)
In-Reply-To: <21151814.1157628883910.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14276114.1157727208852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-477?page=all ]

Michael Neale closed JBRULES-477.
---------------------------------


> BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-477
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-477
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 10:57:30 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Fri, 8 Sep 2006 10:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-107) Find an actual
 machine and load up the new forums here
In-Reply-To: <8992194.1153928592068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7911307.1157727450316.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-107?page=all ]

Sohil Shah resolved JBFORUMS-107.
---------------------------------

    Resolution: Done

These are hosted on http://forums.proto.jboss.com:8080/portal

> Find an actual machine and load up the new forums here
> ------------------------------------------------------
>
>                 Key: JBFORUMS-107
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-107
>             Project: JBoss Forums
>          Issue Type: Sub-task
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 1 day
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:03:43 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 11:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-348) IssueTracker
 example uses nonexisting annotation (Within)
In-Reply-To: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13966331.1157727823758.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-348?page=all ]

Stephan Bublava updated JBSEAM-348:
-----------------------------------


This refers to the latest version available via anoncvs.forge.jboss.com (as of this morning).

> IssueTracker example uses nonexisting annotation (Within)
> ---------------------------------------------------------
>
>                 Key: JBSEAM-348
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>
> org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Fri Sep  8 11:05:43 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 11:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-349) IssueTracker
 @LoggedIn missing @Interceptors annotation
In-Reply-To: <931519.1157705853664.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28874205.1157727943790.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-349?page=all ]

Stephan Bublava updated JBSEAM-349:
-----------------------------------


This refers to the latest version available via anoncvs.forge.jboss.com (as of this morning).

> IssueTracker @LoggedIn missing @Interceptors annotation
> -------------------------------------------------------
>
>                 Key: JBSEAM-349
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-349
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>
> I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:07:44 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Fri, 8 Sep 2006 11:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <8192538.1157728064034.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12343072 ] 
            
Remy Maucherat commented on JBAS-3345:
--------------------------------------

After fixing an issue with JDT not being included, it seems mostly ok.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:29:28 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 8 Sep 2006 11:29:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3636) Port
 HASingletonElectionPolicy to Branch_4_0
Message-ID: <26666341.1157729368785.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port HASingletonElectionPolicy to Branch_4_0
--------------------------------------------

                 Key: JBAS-3636
                 URL: http://jira.jboss.com/jira/browse/JBAS-3636
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Alex Fu
             Fix For: JBossAS-4.0.6.CR1




-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:35:30 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Fri, 8 Sep 2006 11:35:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-61) Apache Tomcat 6.0
In-Reply-To: <21194316.1153309331365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22476837.1157729730591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-61?page=comments#action_12343073 ] 
            
Remy Maucherat commented on JBWEB-61:
-------------------------------------

Comet API finalization is now going along well.

> Apache Tomcat 6.0
> -----------------
>
>                 Key: JBWEB-61
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-61
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Remy Maucherat
>         Assigned To: Remy Maucherat
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 12:39:27 2006
From: jira-events at jboss.com (Manfred Moser (JIRA))
Date: Fri, 8 Sep 2006 12:39:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9926163.1157733567823.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=comments#action_12343076 ] 
            
Manfred Moser commented on JBSEAM-340:
--------------------------------------

I tested the hibernate validator like variables and they work fine with using the ValidatorMessages resource bundle in the entity bean and it bubbles up nicely into the Seam based UI. So this works
    @NotNull
    @Length(min = 2, max=100, message="{person.lastName.length}")
    public String getLastName()
    {
        return lastName;
    }

with 
person.lastName.length=Last Name has to be between {min} and {max} characters long.
in ValidatorMessages.propties and messages.properties copied by the build file.

> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>         Assigned To: Emmanuel Bernard
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Fri Sep  8 13:49:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 8 Sep 2006 13:49:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1024) Verify theme
 CSS compatible with multiple browsers/OS
In-Reply-To: <12922402.1157647004240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18168218.1157737771667.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1024?page=all ]

Roy Russo resolved JBPORTAL-1024.
---------------------------------

    Resolution: Done

> Verify theme CSS compatible with multiple browsers/OS
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1024
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1024
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 14:35:32 2006
From: jira-events at jboss.com (Sangeetha Pisharody (JIRA))
Date: Fri, 8 Sep 2006 14:35:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-126) Lookup fails
	during failover
Message-ID: <14759844.1157740532490.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ]

Sangeetha Pisharody updated JBCLUSTER-126:
------------------------------------------

    Affects Version/s: Q2Y6

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBCLUSTER-126
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-126
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>             Fix For: Bugs
>
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534) 
> This happened on our test cluster. 
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 14:51:31 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 8 Sep 2006 14:51:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-126) Lookup fails
	during failover
Message-ID: <18900200.1157741491495.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ]

Brian Stansberry resolved JBCLUSTER-126.
----------------------------------------

    Resolution: Rejected

Please discuss on user forum at http://www.jboss.com/index.html?module=bb&op=viewforum&f=64 before opening a bug.  Also, please file Application Server bugs under the Application Server project, not the Cluster project.  The Cluster project is for high-level planning, and bugs or fixes there can't be associated with specific releases.  Not blaming you for reporting here; it's confusing :)

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBCLUSTER-126
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-126
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>             Fix For: Bugs
>
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534) 
> This happened on our test cluster. 
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 15:15:31 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Fri, 8 Sep 2006 15:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3637) Way to set JNDI
 properties for twiddle
Message-ID: <8081975.1157742931112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Way to set JNDI properties for twiddle
--------------------------------------

                 Key: JBAS-3637
                 URL: http://jira.jboss.com/jira/browse/JBAS-3637
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Owen Taylor
            Priority: Minor


It is frequently useful to be able to set JDNI properties when running twiddle - for example,
you might want to set jnp.disableDiscovery when checking the status of a particular server
that might not be running.

Right now, this is difficult to do. You can export a JBOSS_CLASSPATH
which contains a jndi.properties file before running twiddle.sh, but then you have to
include all the standard jars in it, which is quite annoying.

A pssible fixes would be one of:

 A) A way to prepend elements to JBOSS_CLASSPATH without disabling the default
  construction (also useful for getting a log4j.properties that doesn't drop twiddle.log
  in the cwd, perhaps)
 
 B) A command line option for specifying a particular properties file to load and pass
  to 'new InitialContext()' (slightly more convenient than A)

 C) A command line option to define particular properties:

    twiddle.sh -jnpProperty=jnp.disableDiscovery=true

  (Or some better syntax)

The twiddle code actually does:

         Properties props = new Properties(System.getProperties());
         props.put(Context.PROVIDER_URL, serverURL);
         ctx = new InitialContext(props);

In the case where a server URL is set, so there may have been intention that twiddle.sh -Djnp.disableDiscovery=true
would work, but AFAIK property inheritance doesn't work in that place - only the properties directly in props take 
effect, and system properties won't be looked at in the other code path either.


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 15:57:27 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Fri, 8 Sep 2006 15:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-336) core reteoo
 implementation for 'accumulate'
Message-ID: <25775972.1157745447829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-336?page=all ]

Edson Tirelli resolved JBRULES-336.
-----------------------------------

    Resolution: Done

Fixing minor bugs and finishing the implementation. Commited to trunk in revision #6130:

----------------------
JBRULES-217: add Accumulate Conditional Element

  * JBRULES-336:
    - Fixing minor bugs
    - Updating test cases
  * JBRULES-337:
    - Fixing minor bugs
    - Adding integration tests

  * Removing System.out from test cases
----------------------

Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/Cheesery.java
Sending        drools-compiler/src/test/java/org/drools/Person.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/HelloWorld.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/errors_in_rule.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/evalmodify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/not_with_bindings_rule_test.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/null_behaviour.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_AccumulateModify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_AgendaGroups.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_FunctionInConsequence.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_OrWithBindings.drl
Sending        drools-core/src/main/java/org/drools/common/DefaultAgenda.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Sending        drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data .........................
Committed revision 6130.


> core reteoo implementation for 'accumulate'
> -------------------------------------------
>
>                 Key: JBRULES-336
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-336
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 15:57:27 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Fri, 8 Sep 2006 15:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-337) language support
 for 'accumulate'
Message-ID: <20500859.1157745447993.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-337?page=all ]

Edson Tirelli resolved JBRULES-337.
-----------------------------------

    Resolution: Done

Fixing minor bugs and finishing the implementation. Commited to trunk in revision #6130:

----------------------
JBRULES-217: add Accumulate Conditional Element

  * JBRULES-336:
    - Fixing minor bugs
    - Updating test cases
  * JBRULES-337:
    - Fixing minor bugs
    - Adding integration tests

  * Removing System.out from test cases
----------------------

Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/Cheesery.java
Sending        drools-compiler/src/test/java/org/drools/Person.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/HelloWorld.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/errors_in_rule.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/evalmodify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/not_with_bindings_rule_test.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/null_behaviour.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_AccumulateModify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_AgendaGroups.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_FunctionInConsequence.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_OrWithBindings.drl
Sending        drools-core/src/main/java/org/drools/common/DefaultAgenda.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Sending        drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data .........................
Committed revision 6130.


> language support for 'accumulate'
> ---------------------------------
>
>                 Key: JBRULES-337
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-337
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 16:43:30 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 8 Sep 2006 16:43:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-3) svn move of security
 from jbossas/trunk to jbossas/projects
In-Reply-To: <6196176.1157480847807.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31147412.1157748210404.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-3?page=all ]

Anil Saldhana closed SECURITY-3.
--------------------------------

    Resolution: Done

https://svn.jboss.org/repos/jbossas/projects/security/trunk/

> svn move of security from jbossas/trunk to jbossas/projects
> -----------------------------------------------------------
>
>                 Key: SECURITY-3
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-3
>             Project: JBoss Security
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Perform a svn move of the security module from jbossas/trunk to jbossas/projects

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 17:11:30 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 8 Sep 2006 17:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-1) Move source
 repository from trunk to projects
In-Reply-To: <2995519.1157476652735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1424248.1157749890103.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-1?page=all ]

Anil Saldhana closed SECURITY-1.
--------------------------------

    Resolution: Done

Emailed the dev-list.  Cruisecontrol build has confirmed that HEAD builds with no issues.

http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060908163425Lbuild.2293

Passing to QA for security project build verification.

> Move source repository from trunk to projects
> ---------------------------------------------
>
>                 Key: SECURITY-1
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-1
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Scott has expressed a desire to see the security project act as the model project to have a SPI and a JBossAS implementation. 
> The first step in this exercize is to move the source repository from jbossas/trunk  to https://svn.jboss.org/repos/jbossas/projects/  (Reference will be the microcontainer project)

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:11:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 8 Sep 2006 18:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1026) Fix Tabs CSS to
 work with existing Navigation CSS
In-Reply-To: <9596533.1157655703858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7439649.1157753489254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1026?page=all ]

Roy Russo resolved JBPORTAL-1026.
---------------------------------

    Resolution: Done

> Fix Tabs CSS to work with existing Navigation CSS
> -------------------------------------------------
>
>                 Key: JBPORTAL-1026
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1026
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:11:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 8 Sep 2006 18:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1027) New Renderer
	for New UI
In-Reply-To: <24226605.1157656063859.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16999451.1157753489362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1027?page=all ]

Roy Russo resolved JBPORTAL-1027.
---------------------------------

    Resolution: Rejected

new renderer not need for new ui, but will be for dnd.

> New Renderer for New UI
> -----------------------
>
>                 Key: JBPORTAL-1027
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1027
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Develop new Renderer class for new layout/theme.
> The new usability requires additional functionality, that requires a new renderer:
> 1. New icon placement: ie, the remove window icon.
> 2. New region for Adding Content to a page.
> Issues: New renderer will not be compatible with previous themes/layouts.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:25:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-596) Lease doesn't work
 if client has two connections opened when using callbacks
Message-ID: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lease doesn't work if client has two connections opened when using callbacks
----------------------------------------------------------------------------

                 Key: JBREM-596
                 URL: http://jira.jboss.com/jira/browse/JBREM-596
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: callbacks
            Reporter: Clebert Suconic
         Assigned To: Tom  Elrod


If you have two connections, one of them is using CallBack the Lease is just stopped.

I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.

Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.

You can look at cruisecontrol results at this URL:

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html

and

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html


I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.



Here is the code:


	   public void testSimplestDurableSubscription() throws Exception
	   {
	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
	      
	      Connection conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();

	      Connection conn2 = cf.createConnection();
	      conn2.setClientID("client2");
	      conn2.start();

	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);

	      MessageProducer prod = s.createProducer(topic);
	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);

	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");

	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
	      
	      
	      for (int i=0;i<10;i++)
	      {
	    	  prod.send(s.createTextMessage("k"+i));
	      }
	      s.commit();

	      conn.close();
	      conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();
	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      durable = s.createDurableSubscriber(topic, "subs1");

	      for (int i=0;i<2;i++)
	      {
	    	  TextMessage tm = (TextMessage)durable.receive(1000);
	    	  assertNotNull(tm);
	    	  s.commit();
	    	  System.out.println(tm.getText());
	    	  assertEquals("k" + i, tm.getText());
	      }
	      
	      //conn.close();-- do not remote this comment. It was meant to not close the connection

	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
	   }


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:29:27 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:29:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25435734.1157754567110.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Assignee: Tom  Elrod  (was: Clebert Suconic)
    Priority: Critical  (was: Major)

Tom, I'm assigning this task to you but please assign me back when you have closed JBREM-596

> Crash Test failure on Durable Subscriber
> ----------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> DurableSubscriberCrashTest1 and 2 are failing.
> The routine that verifies if a connection is broken is only called upon communication exceptions. 
> If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:31:27 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Fri, 8 Sep 2006 18:31:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-480) update
 documentation with 'accumulate' information
Message-ID: <10536387.1157754687859.JavaMail.jira@cloud.prod.atl2.jboss.com>

update documentation with 'accumulate' information
--------------------------------------------------

                 Key: JBRULES-480
                 URL: http://jira.jboss.com/jira/browse/JBRULES-480
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli




-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:37:28 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:37:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9540756.1157755048862.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970472#3970472

> Crash Test failure on Durable Subscriber
> ----------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> DurableSubscriberCrashTest1 and 2 are failing.
> The routine that verifies if a connection is broken is only called upon communication exceptions. 
> If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:37:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease doesn't work
 if client has two connections opened when using callbacks
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26536721.1157755049026.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic updated JBREM-596:
----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970472#3970472

> Lease doesn't work if client has two connections opened when using callbacks
> ----------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>
> If you have two connections, one of them is using CallBack the Lease is just stopped.
> I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.
> Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.
> You can look at cruisecontrol results at this URL:
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html
> and
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html
> I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.
> Here is the code:
> 	   public void testSimplestDurableSubscription() throws Exception
> 	   {
> 	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
> 	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
> 	      
> 	      Connection conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      Connection conn2 = cf.createConnection();
> 	      conn2.setClientID("client2");
> 	      conn2.start();
> 	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      MessageProducer prod = s.createProducer(topic);
> 	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);
> 	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
> 	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");
> 	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
> 	      
> 	      
> 	      for (int i=0;i<10;i++)
> 	      {
> 	    	  prod.send(s.createTextMessage("k"+i));
> 	      }
> 	      s.commit();
> 	      conn.close();
> 	      conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      durable = s.createDurableSubscriber(topic, "subs1");
> 	      for (int i=0;i<2;i++)
> 	      {
> 	    	  TextMessage tm = (TextMessage)durable.receive(1000);
> 	    	  assertNotNull(tm);
> 	    	  s.commit();
> 	    	  System.out.println(tm.getText());
> 	    	  assertEquals("k" + i, tm.getText());
> 	      }
> 	      
> 	      //conn.close();-- do not remote this comment. It was meant to not close the connection
> 	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
> 	   }

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 21:16:27 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 8 Sep 2006 21:16:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-761) Make connecting
 the channel and state transfer an atomic part of startup
Message-ID: <22897707.1157764587331.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make connecting the channel and state transfer an atomic part of startup
------------------------------------------------------------------------

                 Key: JBCACHE-761
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-761
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani


If an exception is thrown during initial state transfer, the channel should be disconnected.  The exception will propagate out of startService(), which in the AS will leave the cache service in an incompletely deployed state.  But the current code leaves the channel connected, leaving a "zombie" member of the group.

Probably need to alter stopService() as well to ensure it can handle an already disconnected channel.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:21:29 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-302) Deadlock with TCP and
 loopback=true
Message-ID: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock with TCP and loopback=true
-----------------------------------

                 Key: JGRP-302
                 URL: http://jira.jboss.com/jira/browse/JGRP-302
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


"TimeScheduler.Thread":
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
        - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.FD.up(FD.java:274)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.Discovery.up(Discovery.java:275)
        at org.jgroups.protocols.MPING.up(MPING.java:152)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
        at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
        at org.jgroups.protocols.TP.doSend(TP.java:934)
        at org.jgroups.protocols.TP.send(TP.java:923)
        - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
        at org.jgroups.protocols.TP.down(TP.java:712)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.Discovery.down(Discovery.java:333)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
        at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
        - locked <0x1056bf90> (a java.lang.Object)
        at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
        - locked <0x1056bf78> (a java.util.Vector)
        at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
        at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
        at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
        at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)


"IncomingMessageHandler (channel=DrawGroupDemo)":
        at org.jgroups.protocols.TP.send(TP.java:922)
        - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
        at org.jgroups.protocols.TP.down(TP.java:712)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.Discovery.down(Discovery.java:333)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.FD.down(FD.java:313)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
        - locked <0x1056b9d0> (a java.util.Hashtable)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.FD.up(FD.java:259)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.Discovery.up(Discovery.java:225)
        at org.jgroups.protocols.MPING.up(MPING.java:152)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
        at org.jgroups.protocols.TP.access$700(TP.java:45)
        at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
        at java.lang.Thread.run(Thread.java:534)

Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:21:29 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-302) Deadlock with TCP
 and loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14605943.1157790089453.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-302?page=comments#action_12343099 ] 
            
Bela Ban commented on JGRP-302:
-------------------------------

SOLUTION: pass down ARE-YOU-ALIVE messages in VERIFY_SUSPECT.verifySuspect() outside the scope of the synchronized(suspects) statement

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:23:29 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-303) Verify that all
 synchronized statements have short scopes
Message-ID: <292182.1157790209387.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

        


From jira-events at jboss.com  Sat Sep  9 04:29:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:29:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-304) Verify that MergeView
 is marshalled/unmarshalled correctly
Message-ID: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>

Verify that MergeView is marshalled/unmarshalled correctly
----------------------------------------------------------

                 Key: JGRP-304
                 URL: http://jira.jboss.com/jira/browse/JGRP-304
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :

public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
        super.readFrom(in);
        short len=in.readShort();
        if(len > 0) {
            View v;
            subgroups=new Vector();
            for(int i=0; i < len; i++) {
                v=new View(); // <========= here 
                v.readFrom(in);
                subgroups.add(v);
            }
        }
    }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:29:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:29:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-304) Verify that
 MergeView is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14289304.1157790568664.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-304?page=comments#action_12343100 ] 
            
Bela Ban commented on JGRP-304:
-------------------------------

SOLUTION: we need to encode the type of view: View or MergeView, for each view in the subgroups, and create either Views or MergeViews accordingly

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:35:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:35:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-304) Verify that MergeView
 is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6310666.1157790928556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-304?page=all ]

Bela Ban updated JGRP-304:
--------------------------

    Issue Type: Bug  (was: Task)

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:13:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Sat, 9 Sep 2006 08:13:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-762) Configuration
 object enhancements
Message-ID: <17732187.1157804023738.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configuration object enhancements
---------------------------------

                 Key: JBCACHE-762
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-762
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.0


1.  Why isn't there a CacheFactory.createCache() (using the default configuration)
2.  I think it would be useful to have a static method in Configuration which returns the default config, so we could do: Cache c=new DefaultCacheFactory().createCache(Configuration.getDefault())
3.  Configuration should have a copy() or clone() method, so we can reuse a config, and make small modifications
4.  Make Configuration serializable (ship them around ?)

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:39:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-302) Deadlock with TCP
 and loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25077212.1157805583855.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-302?page=comments#action_12343101 ] 
            
Bela Ban commented on JGRP-302:
-------------------------------

Fixed according to solution, still needs to be verified though

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:45:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-305) TCP suspects a member
 P if it encounters an exception sending on the socket to P
Message-ID: <31530499.1157805943841.JavaMail.jira@cloud.prod.atl2.jboss.com>

TCP suspects a member P if it encounters an exception sending on the socket to P
--------------------------------------------------------------------------------

                 Key: JGRP-305
                 URL: http://jira.jboss.com/jira/browse/JGRP-305
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


The transport should not emit suspicions, because that's the task of the failure detection protocol (FD, FD_SOCK). Now, this won't happen unless suspect_on_send_failure is set to true (default=false)

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:45:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-305) TCP suspects a
 member P if it encounters an exception sending on the socket to P
In-Reply-To: <31530499.1157805943841.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15406062.1157805943966.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-305?page=all ]

Bela Ban resolved JGRP-305.
---------------------------

    Resolution: Done

> TCP suspects a member P if it encounters an exception sending on the socket to P
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-305
>                 URL: http://jira.jboss.com/jira/browse/JGRP-305
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> The transport should not emit suspicions, because that's the task of the failure detection protocol (FD, FD_SOCK). Now, this won't happen unless suspect_on_send_failure is set to true (default=false)

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:51:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13333067.1157806303835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban updated JGRP-302:
--------------------------

    Attachment: bela_org.xml

TCP config which caused the deadlock

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:51:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23918332.1157806303944.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban updated JGRP-302:
--------------------------

    Attachment:     (was: bela_org.xml)

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:53:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28438443.1157806423793.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban updated JGRP-302:
--------------------------

    Attachment: bela_org.xml

TCP config which caused the deadlock.
To reproduce:
- Start Draw with bela.xml on A,B,C
- Pull the plug on A and B
- C will have the deadlock

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>         Attachments: bela_org.xml
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:59:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-306) FD_SOCK doesn't work
 with TCP and loopback=true
Message-ID: <28243156.1157806783784.JavaMail.jira@cloud.prod.atl2.jboss.com>

FD_SOCK doesn't work with TCP and loopback=true
-----------------------------------------------

                 Key: JGRP-306
                 URL: http://jira.jboss.com/jira/browse/JGRP-306
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


When pulling the plug. Could be the result of http://jira.jboss.com/jira/browse/JGRP-302. If that's the case, then this issue here is not a bug

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:17:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 09:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-304) Verify that
 MergeView is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13419046.1157807863893.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-304?page=comments#action_12343104 ] 
            
Bela Ban commented on JGRP-304:
-------------------------------

The unit test which fails is StreamableTest.testMergeView()

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:29:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 09:29:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-304) Verify that
 MergeView is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31808315.1157808583795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-304?page=all ]

Bela Ban resolved JGRP-304.
---------------------------

    Resolution: Done

fixed according to proposed solution

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:53:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 9 Sep 2006 09:53:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3434) Produce the
 Installer for 4.0.5.GA
In-Reply-To: <26621920.1153999031462.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23068295.1157810024391.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3434?page=all ]

Dimitris Andreadis updated JBAS-3434:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)
          Summary: Produce the Installer for 4.0.5.GA  (was: Produce the Installer for 4.0.5.CR1)

Agreed that installer will only be released only for production releases (GA/SP), not candidate releases.

> Produce the Installer for 4.0.5.GA
> ----------------------------------
>
>                 Key: JBAS-3434
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3434
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>            Reporter: Dimitris Andreadis
>         Assigned To: Alex Pinkin
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Task to hold installer related issues for this release.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:59:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 09:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26412536.1157810383806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban resolved JGRP-302.
---------------------------

    Resolution: Done

Tested successfully on 2 boxes (3 members on one, 2 on the others).
Pulled the plug on one box, then on the other, then on both
Pulled the plug on the switch
Pulled the plug on the switch's power supply
SUCCESS

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>         Attachments: bela_org.xml
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:03:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-306) FD_SOCK doesn't work
 with TCP and loopback=true
In-Reply-To: <28243156.1157806783784.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19677837.1157810623808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-306?page=all ]

Bela Ban resolved JGRP-306.
---------------------------

    Resolution: Done

Depended on 302. Once 302 was fixed, this issue disappeared

> FD_SOCK doesn't work with TCP and loopback=true
> -----------------------------------------------
>
>                 Key: JGRP-306
>                 URL: http://jira.jboss.com/jira/browse/JGRP-306
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> When pulling the plug. Could be the result of http://jira.jboss.com/jira/browse/JGRP-302. If that's the case, then this issue here is not a bug

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:17:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-307) Run testsuite in
	Fedore Core 3
Message-ID: <9618913.1157811463886.JavaMail.jira@cloud.prod.atl2.jboss.com>

Run testsuite in Fedore Core 3
------------------------------

                 Key: JGRP-307
                 URL: http://jira.jboss.com/jira/browse/JGRP-307
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Optional
             Fix For: 2.4


A user reported some failures

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:33:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-308) Upgrade
 commons-logging from 1.0.3 to 1.1.0
Message-ID: <22502118.1157812423881.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade commons-logging from 1.0.3 to 1.1.0
-------------------------------------------

                 Key: JGRP-308
                 URL: http://jira.jboss.com/jira/browse/JGRP-308
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.5


Needs some testing

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:33:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:33:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-309) Upgrade log4j from
	1.2.8 to 1.2.13
Message-ID: <6267936.1157812424014.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade log4j from 1.2.8 to 1.2.13
----------------------------------

                 Key: JGRP-309
                 URL: http://jira.jboss.com/jira/browse/JGRP-309
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.5


Need some testing

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 11:15:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 9 Sep 2006 11:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3605) test failures
 org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase
 (jrockit)
In-Reply-To: <9882655.1157134903814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23677316.1157814943847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3605?page=all ]

Dimitris Andreadis closed JBAS-3605.
------------------------------------

         Assignee: Dimitris Andreadis
    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

      // JBAS-3605, the execution order of tests in this test case is important
      // so it must be defined explicitly when running under some JVMs
      TestSuite suite = new TestSuite();
      suite.addTest(new JMXInvokerUnitTestCase("testGetSomething"));
      suite.addTest(new JMXInvokerUnitTestCase("testGetCustom"));
      suite.addTest(new JMXInvokerUnitTestCase("testGetCustomXMBean"));
      suite.addTest(new JMXInvokerUnitTestCase("testGetXMBeanInfo"));
      suite.addTest(new JMXInvokerUnitTestCase("testXMBeanDoSomething"));
      suite.addTest(new JMXInvokerUnitTestCase("testSetCustom"));
      suite.addTest(new JMXInvokerUnitTestCase("testClassNotFoundException"));
      suite.addTest(new JMXInvokerUnitTestCase("testNotification"));
      suite.addTest(new JMXInvokerUnitTestCase("testNotificationWithBadListener"));
      suite.addTest(new JMXInvokerUnitTestCase("testServerInfoViaHttp"));
      
      return getDeploySetup(suite, "invoker-adaptor-test.ear");

> test failures org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase (jrockit)
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3605
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testGetCustom Failure expected:<InitialValue> but was:<changed>
> junit.framework.ComparisonFailure: expected:<InitialValue> but was:<changed>
> 	at org.jboss.test.jmx.test.JMXInvokerUnitTestCase.testGetCustom(JMXInvokerUnitTestCase.java:85)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 11:43:28 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 9 Sep 2006 11:43:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3604) 2 failed tests -
 org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
In-Reply-To: <19803940.1157134663902.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8470678.1157816608737.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3604?page=all ]

Dimitris Andreadis closed JBAS-3604.
------------------------------------

         Assignee: Dimitris Andreadis
       Resolution: Done
    Fix Version/s: JBossAS-5.0.0.Beta

The execution order of tests in this test case is important so it must be defined explicitly when running under some JVMs

> 2 failed tests - org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
> ---------------------------------------------------------------------------
>
>                 Key: JBAS-3604
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3604
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testPersistentJndiXMBean Error Hello not bound
> javax.naming.NameNotFoundException: Hello not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
> 	at org.jboss.naming.NamingService.invoke(NamingService.java:354)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.test.jmx.interceptors.JNDIPersistence.invoke(JNDIPersistence.java:114)
> 	at org.jboss.test.jmx.interceptors.JNDISecurity.invoke(JNDISecurity.java:130)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
> 	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 	at $Proxy1.lookup(Ljavax.naming.Name;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testPersistentJndiXMBean(DeployXMBeanUnitTestCase.java:520)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
>  testSecuredJndiXMBean Failure Was able to invoke secretEcho
> junit.framework.AssertionFailedError: Was able to invoke secretEcho
> 	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testSecuredJndiXMBean(DeployXMBeanUnitTestCase.java:459)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Sat Sep  9 11:53:27 2006
From: jira-events at jboss.com (Andreas Mueller (JIRA))
Date: Sat, 9 Sep 2006 11:53:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3343) JCA 1.5 Resource
 Adapter Config Properties cannot be specified
Message-ID: <31032837.1157817207745.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3343?page=comments#action_12343111 ] 
            
Andreas Mueller commented on JBAS-3343:
---------------------------------------

In which release will this issue be fixed? 

The fix is very important because no JCA RA can be properly configured except with cracking the rar and overwriting the default props.

> JCA 1.5 Resource Adapter Config Properties cannot be specified
> --------------------------------------------------------------
>
>                 Key: JBAS-3343
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3343
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: All.
>            Reporter: Andreas Mueller
>         Assigned To: Weston Price
>         Attachments: ra.xml
>
>
> A JCA 1.5 resource adapter might contain config properties in ra.xml. It is not possible in JBoss to override them with -ds.xml file.
> For example, here is an excert of SwiftMQ's intraVM ra.xml:
>   <resourceadapter>
>     <resourceadapter-class>
>       com.swiftmq.connector.v15.ResourceAdapterImpl
>     </resourceadapter-class>
>     <config-property>
>       <config-property-name>ProviderURL</config-property-name>
>       <config-property-type>java.lang.String</config-property-type>
>       <config-property-value>smqp://intravm/timeout=10000</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>IntraVM</config-property-name>
>       <config-property-type>java.lang.Boolean</config-property-type>
>       <config-property-value>true</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>DebugMode</config-property-name>
>       <config-property-type>java.lang.Boolean</config-property-type>
>       <config-property-value>false</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>RouterWorkingDirectory</config-property-name>
>       <config-property-type>java.lang.String</config-property-type>
>       <config-property-value>&lt;swiftmq_dir&gt;/scripts/unix</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>ConfigurationFilename</config-property-name>
>       <config-property-type>java.lang.String</config-property-type>
>       <config-property-value>../../config/router1/routerconfig.xml</config-property-value>
>     </config-property>
> It is not possible to overwrite them during deployment. It is only possible to specify the config properties of the ManagedConnectionFactory in -ds.xml.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 13:31:27 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sat, 9 Sep 2006 13:31:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3456) JSP page not compiled
 while using JDK5.0_7 in JBoss 4.0.2
In-Reply-To: <21972994.1154507351343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2401909.1157823087532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3456?page=all ]

Scott M Stark closed JBAS-3456.
-------------------------------

    Resolution: Out of Date

See the " Using JDK5 Features in JSP Pages" section of:
http://wiki.jboss.org/wiki/Wiki.jsp?page=402UpgradeIssues


> JSP page not compiled while using JDK5.0_7 in JBoss 4.0.2
> ---------------------------------------------------------
>
>                 Key: JBAS-3456
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3456
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP, JBoss 4.0.2, JDK 5.0_7 (the lastest version)
>            Reporter: Sasi Levi
>
> I deployed my war application and tried to run JSP that include feature of JDK 5.0, I got error of syntax.
> The code is List<String> list = new ArrayList<String>();
> I checked the run script of the JBoss and I saw  mention of the JAVAC for the JSP, by default is to support JDK of sun.
>        

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 22:45:27 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Sat, 9 Sep 2006 22:45:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease doesn't work
 if client has two connections opened when using callbacks
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27251787.1157856327813.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Tom  Elrod updated JBREM-596:
-----------------------------

        Fix Version/s: 2.2.0.Beta1 (Bluto)
    Affects Version/s: 2.0.0.GA (Boon)

> Lease doesn't work if client has two connections opened when using callbacks
> ----------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you have two connections, one of them is using CallBack the Lease is just stopped.
> I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.
> Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.
> You can look at cruisecontrol results at this URL:
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html
> and
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html
> I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.
> Here is the code:
> 	   public void testSimplestDurableSubscription() throws Exception
> 	   {
> 	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
> 	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
> 	      
> 	      Connection conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      Connection conn2 = cf.createConnection();
> 	      conn2.setClientID("client2");
> 	      conn2.start();
> 	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      MessageProducer prod = s.createProducer(topic);
> 	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);
> 	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
> 	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");
> 	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
> 	      
> 	      
> 	      for (int i=0;i<10;i++)
> 	      {
> 	    	  prod.send(s.createTextMessage("k"+i));
> 	      }
> 	      s.commit();
> 	      conn.close();
> 	      conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      durable = s.createDurableSubscriber(topic, "subs1");
> 	      for (int i=0;i<2;i++)
> 	      {
> 	    	  TextMessage tm = (TextMessage)durable.receive(1000);
> 	    	  assertNotNull(tm);
> 	    	  s.commit();
> 	    	  System.out.println(tm.getText());
> 	    	  assertEquals("k" + i, tm.getText());
> 	      }
> 	      
> 	      //conn.close();-- do not remote this comment. It was meant to not close the connection
> 	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
> 	   }

-- 
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

        


From jira-events at jboss.com  Sun Sep 10 02:47:30 2006
From: jira-events at jboss.com (Basel Al-Mustafa (JIRA))
Date: Sun, 10 Sep 2006 02:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-350) High conversation
 state number causes ui:repeat to show a single item
Message-ID: <852986.1157870850894.JavaMail.jira@cloud.prod.atl2.jboss.com>

High conversation state number causes ui:repeat to show a single item
---------------------------------------------------------------------

                 Key: JBSEAM-350
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-350
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.1
         Environment: CentOS i686, JDK 1.5.0_06-b05, MyFaces 1.1.3, Facelets 1.1.11, JBoss 4.0.4 with EJB3 RC8 FD
            Reporter: Basel Al-Mustafa


When the conversation state number goes up to around 4750 the ui:repeat element stops showing the compete list of items. Rather than that only a single item is displayed even though both of the database query and the SLSB page action return several items. The production server log and the source code can be found in the associated JBoss Forum Reference.

-- 
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

        


From MAILER-DAEMON at lists.jboss.org  Sun Sep 10 09:33:49 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Sun, 10 Sep 2006 09:33:49 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609101333.k8ADXnXC027312@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From jira-events at jboss.com  Sun Sep 10 17:34:27 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sun, 10 Sep 2006 17:34:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-444) patch to support
 Notes attribute on decision table Package
In-Reply-To: <9769524.1156268351914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28000592.1157924067855.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-444?page=all ]

Mark Proctor updated JBRULES-444:
---------------------------------

        Fix Version/s: 3.0.5
                           (was: 3.0.4)
    Affects Version/s:     (was: 3.0.4)

> patch to support Notes attribute on decision table Package
> ----------------------------------------------------------
>
>                 Key: JBRULES-444
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-444
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: G?bor Lipt?k
>         Assigned To: Mark Proctor
>            Priority: Optional
>             Fix For: 3.0.5
>
>         Attachments: jboss_rules_decisiontable_package_notes.diff
>
>
> patch attached

-- 
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

        


From jira-events at jboss.com  Sun Sep 10 17:48:30 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sun, 10 Sep 2006 17:48:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-481)
 LeftInputAdater.updateNewNode does incorrect propagation
Message-ID: <22024033.1157924910095.JavaMail.jira@cloud.prod.atl2.jboss.com>

LeftInputAdater.updateNewNode does incorrect propagation
--------------------------------------------------------

                 Key: JBRULES-481
                 URL: http://jira.jboss.com/jira/browse/JBRULES-481
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions: 3.0.4
            Reporter: Mark Proctor
         Assigned To: Edson Tirelli
             Fix For: 3.0.5, 3.1-m1


        // Get the newly attached TupleSink
        final TupleSink sink = (TupleSink) getTupleSinks().get( getTupleSinks().size() - 1 );

        // Iterate the memory and assert all tuples into the newly attached TupleSink
        final Map memory = (Map) workingMemory.getNodeMemory( this );
        for ( final Iterator it = memory.values().iterator(); it.hasNext(); ) {
            final LinkedList list = (LinkedList) it.next();
            for ( LinkedListNode node = list.getFirst(); node != null; node = node.getNext() ) {
                sink.assertTuple( (ReteTuple) ((LinkedListObjectWrapper) node).getObject(),
                                  context,
                                  workingMemory );
            }
        }

We get the last Sink but then we send through ALL tuples in the list to that single sink. yet we know that each tuple is for a specific sink. we instead should grab the handle and create a new tuple which we add to the list.

-- 
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

        


From jira-events at jboss.com  Sun Sep 10 21:08:43 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Sun, 10 Sep 2006 21:08:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-482) ACTIVATION-GROUP
 not processed by ActionType
Message-ID: <16529337.1157936923871.JavaMail.jira@cloud.prod.atl2.jboss.com>

ACTIVATION-GROUP not processed by ActionType
--------------------------------------------

                 Key: JBRULES-482
                 URL: http://jira.jboss.com/jira/browse/JBRULES-482
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Steven Williams
         Assigned To: Mark Proctor


The code in ActionType has the following:
 
else if ( value.toUpperCase().startsWith( "X" ) || value.toUpperCase().equals( "ACTIVATION-GROUP" ) )

but above this is a check for startsWith("A") to catch Actions which will always take precedence. Maybe it would be better to check for the full names first and then for the single letter option.

In the documentation it actually specifies that "XOR-GROUP" should be used, so the other option may be to just remove the "ACTIVATION-GROUP" check, however the current code means new options (such as agenda group for instance) would have to use letters that don't really make sense.


-- 
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

        


From c11 at fullmailmarket.com  Mon Sep 11 00:41:10 2006
From: c11 at fullmailmarket.com (Carrier 179 (www.179.cl))
Date: Mon, 11 Sep 2006 00:41:10 -0400
Subject: [jboss-jira] SOLO EL CARRIER 179 LE DA CREDITO A SU
	LLAMADA...APROVECHE
Message-ID: <200609110441.k8B4fAc6006009@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060911/1e38f1db/attachment.html 

From workfromhome at yahoo.com  Mon Sep 11 12:22:55 2006
From: workfromhome at yahoo.com (ªÔ³Õ¹Øª)
Date: Mon, 11 Sep 2006 12:22:55
Subject: [jboss-jira] =?iso-8859-1?q?=C3=E9=CD=B9=E6_=CA=C3=E9=D2=A7=24?=
Message-ID: <200609110522.k8B5MtAD006679@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060911/c53cb126/attachment.html 

From MAILER-DAEMON at lists.jboss.org  Mon Sep 11 03:09:04 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Mon, 11 Sep 2006 03:09:04 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609110709.k8B794Os008196@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From MAILER-DAEMON at lists.jboss.org  Mon Sep 11 03:09:33 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Mon, 11 Sep 2006 03:09:33 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609110709.k8B79Xpa008229@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From jira-events at jboss.com  Mon Sep 11 03:22:44 2006
From: jira-events at jboss.com (Roel Adriaensens (JIRA))
Date: Mon, 11 Sep 2006 03:22:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3638) Extra option for
 Hibernate MBean
 to specify which modules should be scanned for hbm files
Message-ID: <6237533.1157959364112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Extra option for Hibernate MBean to specify which modules should be scanned for hbm files
-----------------------------------------------------------------------------------------

                 Key: JBAS-3638
                 URL: http://jira.jboss.com/jira/browse/JBAS-3638
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Hibernate service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Roel Adriaensens
         Assigned To: Steve Ebersole


We have an ear which contains a set of modules and multiple hibernate session factories (via Hibernate MBean). The complication is that a session factory might need hbm files from multiple modules. This is not possible now since the Hibernate MBean will scan either only the har module or the complete ear. 
So it would be nice if the JBoss Hibernate MBean would provide the option to specify which modules (jars) of the ear must be scanned for hbm mapping files. 

Now, we can't use the option of having multiple *.har modules  in the *.ear, with one *.har for each session factory. We have different projects and each project leads to an artifact (eg. jar, har,sar,...). Some of those projects must use the same session factory, but the mapping files are distributed over multiple artifacts (projects). So it's not possible to have *.har for each of the session factories. Also if we should stick to the *.har, we should split every project into a 'persistence unit' (-> the har) and a 'ejb' jar (which contains the ejb3 session beans etc..). We also don't want to have one project for things that correspond to one session factory. There are different sets of mapping files that are maintained by different teams, but actually belong to the same session factory. 

The alternative would be to have a *.ear for each session factory and then turn on the scanning of the entire *.ear. 
But to me it seems better to have one *.ear that contains multiple modules and multiple session factories + the option for each session factory to indicate which modules should be scanned for mapping files.





-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:30:43 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Mon, 11 Sep 2006 03:30:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-483) Open Decision
 Table API to allow custom RuleSheetListeners
Message-ID: <21379798.1157959843818.JavaMail.jira@cloud.prod.atl2.jboss.com>

Open Decision Table API to allow custom RuleSheetListeners
----------------------------------------------------------

                 Key: JBRULES-483
                 URL: http://jira.jboss.com/jira/browse/JBRULES-483
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Steven Williams
         Assigned To: Mark Proctor


I have a need for a different format for my decision tables - basically instead of the current format with one row per rule with conditions across the top I need to support a matrix-like structure where both the horizontal and the vertical axes represent conditions and the intersection represents the action. In order to do this I created my own MatrixRuleSheetListener inheriting from RuleSheetListener and overriding certain methods. This all works fine however I had to hack the drools code a little to allow me to do it. I was wondering if it would be possible to open up the API to allow this.

Specifically:

1. add method to org.drools.decisiontable.parser.RuleSheetListener
    protected void addRule(Rule rule)
    {
        this._ruleList.add(rule);
    }
2. add empty protected methods preInitRuleTable(row, column, value) and postInitRuleTable(row, column, value, rule) to org.drools.decisiontable.parser.RuleSheetListener which are called from the start and end of the initRuleTable method.
3. Add agendaGroup property to org.drools.decisiontable.model.Rule
4. Add a new method compile(InputStream, InputType, RuleSheetListener) to org.drools.decisiontable.SpreadsheetCompiler

I have attached these changes to this request.

Steve

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:44:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 11 Sep 2006 03:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-310) Update training to
 use latest version
Message-ID: <13709843.1157960683871.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update training to use latest version
-------------------------------------

                 Key: JGRP-310
                 URL: http://jira.jboss.com/jira/browse/JGRP-310
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.5


- Include 2.5
- Change the labs/slides to use the Receiver (push approach)
- Possibly include a Multiplexer example

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:44:44 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Mon, 11 Sep 2006 03:44:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-483) Open Decision
 Table API to allow custom RuleSheetListeners
In-Reply-To: <21379798.1157959843818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17037718.1157960684105.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-483?page=all ]

Steven Williams updated JBRULES-483:
------------------------------------

    Attachment: RuleSheetListener.java
                SpreadsheetCompiler.java
                Rule.java

Changed files for request

> Open Decision Table API to allow custom RuleSheetListeners
> ----------------------------------------------------------
>
>                 Key: JBRULES-483
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-483
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Steven Williams
>         Assigned To: Mark Proctor
>         Attachments: Rule.java, RuleSheetListener.java, SpreadsheetCompiler.java
>
>
> I have a need for a different format for my decision tables - basically instead of the current format with one row per rule with conditions across the top I need to support a matrix-like structure where both the horizontal and the vertical axes represent conditions and the intersection represents the action. In order to do this I created my own MatrixRuleSheetListener inheriting from RuleSheetListener and overriding certain methods. This all works fine however I had to hack the drools code a little to allow me to do it. I was wondering if it would be possible to open up the API to allow this.
> Specifically:
> 1. add method to org.drools.decisiontable.parser.RuleSheetListener
>     protected void addRule(Rule rule)
>     {
>         this._ruleList.add(rule);
>     }
> 2. add empty protected methods preInitRuleTable(row, column, value) and postInitRuleTable(row, column, value, rule) to org.drools.decisiontable.parser.RuleSheetListener which are called from the start and end of the initRuleTable method.
> 3. Add agendaGroup property to org.drools.decisiontable.model.Rule
> 4. Add a new method compile(InputStream, InputType, RuleSheetListener) to org.drools.decisiontable.SpreadsheetCompiler
> I have attached these changes to this request.
> Steve

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:56:43 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Mon, 11 Sep 2006 03:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-148) Include Tomcat's
 SavedRequest
 object into the replication process in a Jboss-Tomcat clustered environment
 to allow proper Single Sign On capabilities
Message-ID: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>

Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
-----------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBCLUSTER-148
                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
             Project: JBoss Clustering
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: Q2Y6
         Environment: independent
            Reporter: Alberto Rodriguez
         Assigned To: Brian Stansberry
            Priority: Optional


In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.

Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.

The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:42:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2644) Revisit the use of
 the jndi bindings in the tomcat server.xml
Message-ID: <23320001.1157964163934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2644?page=all ]

Dimitris Andreadis updated JBAS-2644:
-------------------------------------

      Component/s: Web (Tomcat) service
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Remy Maucherat

Remy could provide input for this, for the next release.

> Revisit the use of the jndi bindings in the tomcat server.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-2644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We have never supported the declaration of jndi bindings from the tomcat server.xml because we do not use the tomcat jndi service. We should look at whether such bindings just work or can be made to work as a portability aide in moving from standalone tomcat to embedded tomcat.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:42:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:42:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2845) Look at supporting
 web session password update for password change
Message-ID: <25158729.1157964164115.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2845?page=all ]

Dimitris Andreadis updated JBAS-2845:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Anil Saldhana

Anil could provide input, for the next CR release.

> Look at supporting web session password update for password change
> ------------------------------------------------------------------
>
>                 Key: JBAS-2845
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2845
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.6.CR1
>
>
> A common problem  for form authentication is wanting to have a password change feature that does not require a logout/login cycle to update the session id/password association. We need to look into whether there is a secure way to support updating the session password to avoid this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:44:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2895) Extend
 SecureIdentityLoginModule to externalize the secret
Message-ID: <19664548.1157964283902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2895?page=all ]

Dimitris Andreadis updated JBAS-2895:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Extend SecureIdentityLoginModule to externalize the secret
> ----------------------------------------------------------
>
>                 Key: JBAS-2895
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2895
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Security
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The SecureIdentityLoginModule is a simple security by obscurity approach to hiding the jca password. Having the secret used by the PBE externalized with an ability to hash it reversibly would make this more flexible.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:44:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:44:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3019) Add support for CRL
 validation to the certificate based login modules
Message-ID: <26070929.1157964284077.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3019?page=all ]

Dimitris Andreadis updated JBAS-3019:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Anil Saldhana

Anil could look at this for the next release.

> Add support for CRL validation to the certificate based login modules
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3019
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3019
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We need to add support for validating certificates against certificate revocation lists (CRLs).

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:48:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:48:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3022) Add support for
 configuring a DefaultUncaughtExceptionHandler
Message-ID: <10087963.1157964523782.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3022?page=all ]

Dimitris Andreadis updated JBAS-3022:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Add support for configuring a DefaultUncaughtExceptionHandler
> -------------------------------------------------------------
>
>                 Key: JBAS-3022
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3022
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging, MicroContainer bus
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Apparently there can be bad interaction between the jdk default UncaughtExceptionHandler and logging appenders. We should have the ability to install a handler that integrates better with our logging layer.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:50:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:50:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2249) Cleanup the
 org.jboss.naming packaging
Message-ID: <20392635.1157964643905.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2249?page=all ]

Dimitris Andreadis updated JBAS-2249:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Cleanup the org.jboss.naming packaging
> --------------------------------------
>
>                 Key: JBAS-2249
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2249
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Build System, Naming
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Trying to use the jndi naming service in a minimal configuration requires the full jboss.jar. The naming classes should just be merged into the naming module and jnpserver.jar.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:50:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:50:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2340) Development mode
Message-ID: <5981611.1157964644144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2340?page=all ]

Dimitris Andreadis updated JBAS-2340:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Development mode
> ----------------
>
>                 Key: JBAS-2340
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2340
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: System service
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> There are a number of places in the system that have a "development mode" flag or "debug" flag
> which is usually turned on by default.
> We should add a system property that can be configured via a command line option on run.[sh|.bat]
> that is referenced in the configuration.
> It would then be trivial to do:
> ./run.sh --production

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:52:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:52:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2402) EAR deployer does
 not process MANIFEST.MF correctly
Message-ID: <28058203.1157964764047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2402?page=all ]

Dimitris Andreadis updated JBAS-2402:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Feature requests to the next release

> EAR deployer does not process MANIFEST.MF correctly
> ---------------------------------------------------
>
>                 Key: JBAS-2402
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2402
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
>         Environment: Windows 2000 AS, SUN JDK 1.5_04
>            Reporter: Alex Pavlov
>             Fix For: JBossAS-4.0.6.CR1
>
>
> EAR deployer failed to process MANIFEST.MF, bundled with EAR - instead of loading jars from EAR content it will try to locate referenced files in ${jboss.server.home}/deploy  directory.
> EAR layout:
>  Directory of C:\java\jboss\server\default\deploy\ear-rpa.ear
> 10/26/2005  01:14p      <DIR>          .
> 10/26/2005  01:14p      <DIR>          ..
> 10/26/2005  01:09p             227,260 ejb-pwc.jar
> 10/26/2005  01:09p              39,997 ejb-rpatask.jar
> 10/26/2005  01:13p      <DIR>          lib
> 10/26/2005  01:13p      <DIR>          META-INF
> 10/26/2005  01:14p      2,498,160         war-rpa.war
>                2 File(s)        267,257 bytes
>  Directory of C:\java\jboss\server\default\deploy\ear-rpa.ear\lib
> 10/26/2005  01:13p      <DIR>          .
> 10/26/2005  01:13p      <DIR>          ..
> 10/26/2005  01:09p                 324 app-classpath.jar
> 10/26/2005  01:09p              39,523 commons-pool-1.1.jar
> 10/26/2005  01:09p             187,037 edx_client.jar
> 10/26/2005  01:09p             679,520 edx_common.jar
> 10/26/2005  01:09p             120,477 edx_rpa.jar
> 10/26/2005  01:09p              11,408 edx_system.jar
> 10/26/2005  01:09p          11,053,816 jrulesall.jar
> 10/26/2005  01:09p             350,627 log4j-1.2.11.jar
> 10/26/2005  01:09p              40,526 logging.jar
> 10/26/2005  01:09p              44,648 sam.jar
>               10 File(s)     12,527,906 bytes
>  Directory of C:\java\jboss\server\default\deploy\ear-rpa.ear\META-INF
> 10/26/2005  01:13p      <DIR>          .
> 10/26/2005  01:13p      <DIR>          ..
> 10/26/2005  02:00p                 487 application.xml
> 10/26/2005  01:10p                 252 MANIFEST.MF
>                2 File(s)            739 bytes
> EAR's MANIFEST file :
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.2
> Created-By: 1.4.2_06-b03 (Sun Microsystems Inc.)
> Built-By: apavlov
> Implementation-Title: rpa
> Implementation-Version: 5.0
> Class-Path: lib/app-classpath.jar
> Fragment of server log file:
> 2005-10-25 17:03:48,153 DEBUG [org.jboss.web.tomcat.tc5.jasper.TagLibCache] Scanning for tlds in: file:/C:/java/jboss/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs/myfaces-impl.jar
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.deployment.MainDeployer] Undeploying file:/C:/java/jboss/server/default/deploy/edx_rpa.jar
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] Unregistering cl=org.jboss.mx.loading.UnifiedClassLoader3 at d0005e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45781edx_rpa.jar ,addedOrder=43}
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] UnifiedLoaderRepository removed(true) org.jboss.mx.loading.UnifiedClassLoader3 at d0005e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45781edx_rpa.jar ,addedOrder=43}
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.util.file.Files] Failed to delete dir: C:\java\jboss\server\default\tmp\deploy\tmp45781edx_rpa.jar
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.deployment.DeploymentInfo] Could not delete file:/C:/java/jboss/server/default/tmp/deploy/tmp45781edx_rpa.jar restart will delete it
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.deployment.MainDeployer] Undeployed file:/C:/java/jboss/server/default/deploy/edx_rpa.jar
> 2005-10-25 17:06:07,385 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:07,385 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:07,385 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/java/jboss/server/default/deploy/ear-rpa.ear -> C:\java\jboss\server\default\tmp\deploy\tmp45787ear-rpa.ear
> 2005-10-25 17:06:08,839 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.EARDeployer at cade31
> 2005-10-25 17:06:08,839 INFO  [org.jboss.deployment.EARDeployer] Init J2EE application: file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:08,854 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: META-INF/MANIFEST.MF
> 2005-10-25 17:06:08,854 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: META-INF/application.xml
> 2005-10-25 17:06:08,870 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: ejb-pwc.jar
> 2005-10-25 17:06:08,885 DEBUG [org.jboss.deployment.EARDeployer] Extracted deployable content: ejb-rpatask.jar
> 2005-10-25 17:06:08,885 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/app-classpath.jar
> 2005-10-25 17:06:08,901 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/commons-pool-1.1.jar
> 2005-10-25 17:06:08,901 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_client.jar
> 2005-10-25 17:06:08,948 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_common.jar
> 2005-10-25 17:06:08,948 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_rpa.jar
> 2005-10-25 17:06:08,964 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_system.jar
> 2005-10-25 17:06:10,276 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/jrulesall.jar
> 2005-10-25 17:06:10,464 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/log4j-1.2.11.jar
> 2005-10-25 17:06:10,464 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/logging.jar
> 2005-10-25 17:06:10,479 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/sam.jar
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.EARDeployer] Extracted deployable content: war-rpa.war
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.EARDeployer] Deployment Info: org.jboss.deployment.DeploymentInfo at 5a81f787 { url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/war-rpa.war }
>   deployer: null
>   status: null
>   state: CONSTRUCTED
>   watch: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/war-rpa.war
>   altDD: null
>   lastDeployed: 0
>   lastModified: 0
>   mbeans:
> , isDirectory: false
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.EARDeployer] Deployment Info: org.jboss.deployment.DeploymentInfo at afbc8eb4 { url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar }
>   deployer: null
>   status: null
>   state: CONSTRUCTED
>   watch: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
>   altDD: null
>   lastDeployed: 0
>   lastModified: 0
>   mbeans:
> , isDirectory: false
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 10e790c, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=0}
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 10e790c, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=0}
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=0}
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.ClassLoaderUtils] Multiple class loaders found for pkg: 
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] resolveLibraries: lib/app-classpath.jar
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] new manifest entry for sdi at ear-rpa.ear entry is lib/app-classpath.jar
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] The manifest entry in file:/C:/java/jboss/server/default/deploy/ear-rpa.ear references URL file:/C:/java/jboss/server/default/deploy/lib/app-classpath.jar which could not be opened, entry ignored
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
> org.jboss.deployment.DeploymentException: url file:/C:/java/jboss/server/default/deploy/lib/app-classpath.jar could not be opened, does it exist?
> 	at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:191)
> 	at org.jboss.deployment.MainDeployer.parseManifestLibraries(MainDeployer.java:1101)
> 	at org.jboss.deployment.MainDeployer.init(MainDeployer.java:855)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:780)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> 	at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> 	at $Proxy9.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] found 2 subpackages of file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
> 2005-10-25 17:06:11,104 DEBUG [org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt[jboss.ejb:service=EJBDeployer]
> 2005-10-25 17:06:11,104 DEBUG [org.jboss.ejb.EJBDeployer] init, ejb-rpatask.jar
> 2005-10-25 17:06:11,120 DEBUG [org.jboss.ejb.EJBDeployer] looking for nested deployments in : file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
> 2005-10-25 17:06:11,120 DEBUG [org.jboss.webservice.ServiceDeployer] handleNotification: org.jboss.deployment.SubDeployer.init,ejb-rpatask.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] Added url: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar, to ucl: org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=51}
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] resolveLibraries: lib/app-classpath.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] new manifest entry for sdi at ejb-rpatask.jar entry is lib/app-classpath.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] No deployer found for url: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/lib/app-classpath.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] Added url: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/lib/app-classpath.jar, to ucl: org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=51}
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/war-rpa.war

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 05:19:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 05:19:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3497) (21) test under
 org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException
 (jrockit)
In-Reply-To: <3943595.1155053113119.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20706007.1157966371303.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3497?page=all ]

Dimitris Andreadis closed JBAS-3497.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Alexey Loubyansky)

The execution order of tests in this test case is important so it must be defined explicitly when running under some JVMs

> (21) test under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException (jrockit)
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3497
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3497
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux - dev03 in qa, java: Jrockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> 21 tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:
> No such entity!
> javax.ejb.ObjectNotFoundException: No such entity!
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
> 	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 05:31:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 05:31:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3496) all tests under
 org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
In-Reply-To: <29133751.1155052872676.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30026405.1157967098747.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3496?page=all ]

Dimitris Andreadis closed JBAS-3496.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Alexey Loubyansky)

> all tests under org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3496
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3496
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux -dev03 in qa, JRockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> This error does not happen with Sun JDK1.4.
> All test cases under org.jboss.test.cmp2.cmrtree.test have following error:
> Entity with primary key [.1.A.] already exists
> javax.ejb.DuplicateKeyException: Entity with primary key [.1.A.] already exists
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand.beforeInsert(JDBCInsertPKCreateCommand.java:99)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractCreateCommand.execute(JDBCAbstractCreateCommand.java:150)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:587)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:237)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:225)
> 	at org.jboss.ejb.EntityContainer.createLocalHome(EntityContainer.java:625)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
> 	at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
> 	at $Proxy204.create(ILjava.lang.String;Ljava.lang.String;)Lorg.jboss.test.cmp2.cmrtree.ejb.ALocal;(Unknown 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

        


From jira-events at jboss.com  Mon Sep 11 06:01:31 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 11 Sep 2006 06:01:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-482) ACTIVATION-GROUP
 not processed by ActionType
In-Reply-To: <16529337.1157936923871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24315265.1157968891569.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-482?page=all ]

Michael Neale resolved JBRULES-482.
-----------------------------------

    Resolution: Done
      Assignee: Michael Neale  (was: Mark Proctor)

fixed in trunk only (will only port to 3.0.x on request as there is a documented workaround). 


> ACTIVATION-GROUP not processed by ActionType
> --------------------------------------------
>
>                 Key: JBRULES-482
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-482
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Steven Williams
>         Assigned To: Michael Neale
>
> The code in ActionType has the following:
>  
> else if ( value.toUpperCase().startsWith( "X" ) || value.toUpperCase().equals( "ACTIVATION-GROUP" ) )
> but above this is a check for startsWith("A") to catch Actions which will always take precedence. Maybe it would be better to check for the full names first and then for the single letter option.
> In the documentation it actually specifies that "XOR-GROUP" should be used, so the other option may be to just remove the "ACTIVATION-GROUP" check, however the current code means new options (such as agenda group for instance) would have to use letters that don't really make sense.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:05:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 06:05:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3492) Test Failure with
 JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
In-Reply-To: <31141571.1155047232621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33373761.1157969131285.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3492?page=all ]

Dimitris Andreadis closed JBAS-3492.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Alexey Loubyansky)

Fixed

> Test Failure with JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3492
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3492
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, CMP service
>         Environment: linux - dev03 in qa lab, JRockit - java version "1.4.2_11"
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error
> Error, bean instance was discarded!
> javax.ejb.FinderException: Error, bean instance was discarded!
> 	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer
> On the server log, I see following for the first error in test suite.
> 2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
> 2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
> 2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
> onTesterLocal.runtimeExceptionNoTx():
> java.lang.RuntimeException: Runtime exception without a transaction
>         at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
>         at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
>         at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
>         at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
>         at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
>         at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
>         at org.jboss.ejb.Container.invoke(Container.java:954)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:17:32 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Mon, 11 Sep 2006 06:17:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-761) Make connecting
 the channel and state transfer an atomic part of startup
In-Reply-To: <22897707.1157764587331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19526777.1157969852830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-761?page=all ]

Manik Surtani updated JBCACHE-761:
----------------------------------

        Fix Version/s: 1.4.0.SP2
                       2.0.0
    Affects Version/s: 1.4.0.SP1
                       1.3.0.SP3

> Make connecting the channel and state transfer an atomic part of startup
> ------------------------------------------------------------------------
>
>                 Key: JBCACHE-761
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-761
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 1.4.0.SP2, 2.0.0
>
>
> If an exception is thrown during initial state transfer, the channel should be disconnected.  The exception will propagate out of startService(), which in the AS will leave the cache service in an incompletely deployed state.  But the current code leaves the channel connected, leaving a "zombie" member of the group.
> Probably need to alter stopService() as well to ensure it can handle an already disconnected channel.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:35:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 06:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29390677.1157970929905.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3494?page=comments#action_12343125 ] 
            
Dimitris Andreadis commented on JBAS-3494:
------------------------------------------

Not an ordering issue because it is explicilty defined in this testcase.

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, ClassLoading
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:39:36 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 11 Sep 2006 06:39:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-121) Check recovery
In-Reply-To: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33537487.1157971176935.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-121?page=all ]

Mark Little updated JBTM-121:
-----------------------------

    Component/s: WS-T Implementation

> Check recovery
> --------------
>
>                 Key: JBTM-121
>                 URL: http://jira.jboss.com/jira/browse/JBTM-121
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:57:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 06:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3580) Error in
 org.jboss.test.jbossmq.test.UnackedUnitTestCase
In-Reply-To: <7836020.1156800287434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30386667.1157972249107.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3580?page=all ]

Dimitris Andreadis closed JBAS-3580.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Adrian Brock)

Fixed ordering

> Error in org.jboss.test.jbossmq.test.UnackedUnitTestCase
> --------------------------------------------------------
>
>                 Key: JBAS-3580
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3580
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testDummyLast - Error
> No durable subscription found for subscription: test
> javax.jms.InvalidDestinationException: No durable subscription found for subscription: test
> 	at org.jboss.mq.sm.AbstractStateManager.getDurableTopic(AbstractStateManager.java:164)
> 	at org.jboss.mq.server.JMSDestinationManager.getDurableTopic(JMSDestinationManager.java:777)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.getDurableTopic(JMSServerInterceptorSupport.java:181)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:207)
> 	at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:548)
> 	at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:162)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:214)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Unknown 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

        


From jira-events at jboss.com  Mon Sep 11 07:07:27 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Mon, 11 Sep 2006 07:07:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-136) Define a set of EPRs
 for the Email, Ftp and Database.
Message-ID: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define a set of EPRs for the Email, Ftp and Database.
-----------------------------------------------------

                 Key: JBESB-136
                 URL: http://jira.jboss.com/jira/browse/JBESB-136
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
            Reporter: Arvinder Singh
         Assigned To: Arvinder Singh
             Fix For: 4.0


Define a set of EPRs for the Email, Ftp and Database.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 07:09:27 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Mon, 11 Sep 2006 07:09:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-136) Define a set of EPRs
 for Email, Ftp and Database.
In-Reply-To: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27694361.1157972967580.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-136?page=all ]

Arvinder Singh updated JBESB-136:
---------------------------------

    Description: Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format  (was: Define a set of EPRs for the Email, Ftp and Database.)
        Summary: Define a set of EPRs for Email, Ftp and Database.  (was: Define a set of EPRs for the Email, Ftp and Database.)

> Define a set of EPRs for Email, Ftp and Database.
> -------------------------------------------------
>
>                 Key: JBESB-136
>                 URL: http://jira.jboss.com/jira/browse/JBESB-136
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Arvinder Singh
>         Assigned To: Arvinder Singh
>             Fix For: 4.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 07:57:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 07:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
In-Reply-To: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <427701.1157975849629.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3603?page=all ]

Dimitris Andreadis closed JBAS-3603.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Weston Price)

Fixed the ordering of the tests

> 6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-3603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with
> Transaction already active, cannot nest transactions.
> javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
> 	at org.jboss.tm.TxManager.begin(TxManager.java:209)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)
> OR
> Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
> 	... 16 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 08:35:31 2006
From: jira-events at jboss.com (Morten Hauch (JIRA))
Date: Mon, 11 Sep 2006 08:35:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
Message-ID: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ability for an administrator to add/remove users
------------------------------------------------

                 Key: JBPORTAL-1029
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
            Reporter: Morten Hauch
         Assigned To: Julien Viet


In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 08:35:31 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Mon, 11 Sep 2006 08:35:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-21) Registry service
	interface
Message-ID: <5492093.1157978131897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-21?page=all ]

Kurt Stam reassigned JBESB-21:
------------------------------

    Assignee: Kurt Stam  (was: Mugdho)

> Registry service interface
> --------------------------
>
>                 Key: JBESB-21
>                 URL: http://jira.jboss.com/jira/browse/JBESB-21
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Registry
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Critical
>             Fix For: 4.0
>
>
> We need a registry. It cannot be WS specific, but JAX-R looks like it still matches. Check out what is available in JBossWS (or elsewhere). Assuming we go the JAX-R route (discuss on forum please), then we need stand-alone JAX-R support and a plugin.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 09:01:29 2006
From: jira-events at jboss.com (Morten Hauch (JIRA))
Date: Mon, 11 Sep 2006 09:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25059292.1157979689869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Morten Hauch updated JBPORTAL-1029:
-----------------------------------

    Attachment: userportlet.zip

This zip contains the files needed to solve this issue.
See readme.txt for details.

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>            Reporter: Morten Hauch
>         Assigned To: Julien Viet
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:12:32 2006
From: jira-events at jboss.com (Sangeetha Pisharody (JIRA))
Date: Mon, 11 Sep 2006 10:12:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3639) Lookup fails during
	failover
Message-ID: <8989834.1157983952060.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lookup fails during failover
----------------------------

                 Key: JBAS-3639
                 URL: http://jira.jboss.com/jira/browse/JBAS-3639
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-4.0.4RC1, JBossAS-3.2.6 Final
         Environment: jboss 3.2.6
OS: SUSE LINUX 10
            Reporter: Sangeetha Pisharody
         Assigned To: Brian Stansberry


I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup

Properties p = System.getProperties();
p.put(Context.PROVIDER_URL, "localhost:1100");
Context jndiContext = new InitialContext(p);
jndiContext.lookup("XAConnectionFactory");

I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw

javax.naming.NameNotFoundException: XAConnectionFactory
at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
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:324)
at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
at $Proxy42.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
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:324)
at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
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:324)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:534)

This happened on our test cluster.

On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
Services that lookup XAConnectionFactory threw a similar exception.

I tested with jboss 4.0.4 and the problem still exists

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:27:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Mon, 11 Sep 2006 10:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-597) Allow access to
 underlying stream in marshaller with socket transport
Message-ID: <11807485.1157984863851.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow access to underlying stream in marshaller with socket transport
---------------------------------------------------------------------

                 Key: JBREM-597
                 URL: http://jira.jboss.com/jira/browse/JBREM-597
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Tim Fox
         Assigned To: Tom  Elrod
             Fix For: 2.2.0.Beta1 (Bluto)


Currently the ClientSocketWrapper::createOuputStream always returns an ObjectOutputStream wrapping the underlying socket ouput stream.

This ends up getting passed into the marshaller.

With messaging we'd like to use the underlying socket output stream directly in the marshaller - i.e. we don't want to have to write through an object output stream.

This is because the object output stream adds some overhead in terms of the amount of stuff written to the underlying stream..

A similar reasoning applies to InputStream too.

Any chance of changing the socket transport to pass in the underlying socket stream, not an object output/input stream?

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:35:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 10:35:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1030) Add support for
 utility region in existing renderers
Message-ID: <2242969.1157985343870.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for utility region in existing renderers
----------------------------------------------------

                 Key: JBPORTAL-1030
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1030
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:37:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 11 Sep 2006 10:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17969213.1157985463778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-296?page=all ]

Bela Ban resolved JGRP-296.
---------------------------

    Resolution: Done

done

> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups
> #4 Implement support for both new and old system properties: try to get the value for the new one first (e.g. jgroups.bind_addr), then - if not found - the old one (bind.address). In this case, it probably makes sense to create a function in Util which does this, plus also takes jgroups.ignore.bind_addr into account

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:51:43 2006
From: jira-events at jboss.com (Hany Mesha (JIRA))
Date: Mon, 11 Sep 2006 10:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-762) Configuration
 object enhancements
In-Reply-To: <17732187.1157804023738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10629376.1157986303881.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-762?page=all ]

Hany Mesha reassigned JBCACHE-762:
----------------------------------

    Assignee: Hany Mesha  (was: Manik Surtani)

> Configuration object enhancements
> ---------------------------------
>
>                 Key: JBCACHE-762
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-762
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Hany Mesha
>             Fix For: 2.0.0
>
>
> 1.  Why isn't there a CacheFactory.createCache() (using the default configuration)
> 2.  I think it would be useful to have a static method in Configuration which returns the default config, so we could do: Cache c=new DefaultCacheFactory().createCache(Configuration.getDefault())
> 3.  Configuration should have a copy() or clone() method, so we can reuse a config, and make small modifications
> 4.  Make Configuration serializable (ship them around ?)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:01:44 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 11 Sep 2006 11:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-597) Allow access to
 underlying stream in marshaller with socket transport
In-Reply-To: <11807485.1157984863851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10526410.1157986904894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-597?page=all ]

Tom  Elrod updated JBREM-597:
-----------------------------

          Component/s: transport
    Affects Version/s: 2.0.0.GA (Boon)
             Priority: Critical  (was: Major)

> Allow access to underlying stream in marshaller with socket transport
> ---------------------------------------------------------------------
>
>                 Key: JBREM-597
>                 URL: http://jira.jboss.com/jira/browse/JBREM-597
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tim Fox
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> Currently the ClientSocketWrapper::createOuputStream always returns an ObjectOutputStream wrapping the underlying socket ouput stream.
> This ends up getting passed into the marshaller.
> With messaging we'd like to use the underlying socket output stream directly in the marshaller - i.e. we don't want to have to write through an object output stream.
> This is because the object output stream adds some overhead in terms of the amount of stuff written to the underlying stream..
> A similar reasoning applies to InputStream too.
> Any chance of changing the socket transport to pass in the underlying socket stream, not an object output/input stream?

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:25:43 2006
From: jira-events at jboss.com (Alex Pinkin (JIRA))
Date: Mon, 11 Sep 2006 11:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1031) Update docs with
 info on the latest installer.
Message-ID: <6977550.1157988343845.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update docs with info on the latest installer.
----------------------------------------------

                 Key: JBPORTAL-1031
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1031
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.4 Final
            Reporter: Alex Pinkin
         Assigned To: Roy Russo
             Fix For: 2.4.1 Final


need to mention that latest installer allows to configure datasource.

http://labs.jboss.com/portal/jemsinstaller/downloads

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:33:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 11 Sep 2006 11:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-666) Throw
 javax.ejb.ConcurrentAccessException when two threads access the same SFSB
 instance
In-Reply-To: <29278907.1153950371470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19586494.1157988823950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-666?page=all ]

Carlo de Wolf resolved EJBTHREE-666.
------------------------------------

    Resolution: Done

> Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-666
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> See section 4.13.3 of the EJB Core Contracts specification.
> I need this for Seam.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:40:32 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 11 Sep 2006 11:40:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-666) Throw
 javax.ejb.ConcurrentAccessException when two threads access the same SFSB
 instance
In-Reply-To: <29278907.1153950371470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27169561.1157989232268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-666?page=comments#action_12343138 ] 
            
Gavin King commented on EJBTHREE-666:
-------------------------------------

thanks for the fix :)

> Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-666
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> See section 4.13.3 of the EJB Core Contracts specification.
> I need this for Seam.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:48:35 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Mon, 11 Sep 2006 11:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-484) refactor the core
 reteoo code for sinle and composite propagations
Message-ID: <6257948.1157989715700.JavaMail.jira@cloud.prod.atl2.jboss.com>

refactor the core reteoo code  for sinle and composite propagations
-------------------------------------------------------------------

                 Key: JBRULES-484
                 URL: http://jira.jboss.com/jira/browse/JBRULES-484
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1


The profiling shows that much time is spent in iteration loops. So we  should  look  at using Single and Composite Adapters for propagations. Further we should avoid using ArrayLists and instead use our own custom LinkedList or arrays.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:48:35 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Mon, 11 Sep 2006 11:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-484) refactor the
 core reteoo code for sinle and composite propagations
In-Reply-To: <6257948.1157989715700.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16650160.1157989715853.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-484?page=comments#action_12343139 ] 
            
Mark Proctor commented on JBRULES-484:
--------------------------------------

This jira also includes the refactored alpha node hashing.

> refactor the core reteoo code  for sinle and composite propagations
> -------------------------------------------------------------------
>
>                 Key: JBRULES-484
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-484
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m1
>
>
> The profiling shows that much time is spent in iteration loops. So we  should  look  at using Single and Composite Adapters for propagations. Further we should avoid using ArrayLists and instead use our own custom LinkedList or arrays.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 12:32:32 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Mon, 11 Sep 2006 12:32:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4487714.1157992352984.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Nitzan Niv updated JBCACHE-760:
-------------------------------

    Attachment: CollectionClassHandler.java
                TreeCacheAopListenerTest.java

Attached is a modified CollectionClassHandler that resolves this issue and a modified TestCase that checks it.

The problem is in collectionObjectPut() and it is resolved by putting an initialized AOPInstance in the FQN before putting the collection's Class there.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 12:38:35 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Mon, 11 Sep 2006 12:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10227838.1157992715257.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Manik Surtani reassigned JBCACHE-760:
-------------------------------------

    Assignee: Ben Wang  (was: Manik Surtani)

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:09:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 11 Sep 2006 13:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-311) Use JAVA_HOME in path
 to java executable
Message-ID: <18417266.1157994583822.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use JAVA_HOME in path to java executable
----------------------------------------

                 Key: JGRP-311
                 URL: http://jira.jboss.com/jira/browse/JGRP-311
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: 2.4


In build.bat and build.sh, JAVA_HOME is used in building the classpath but not in creating the path to the java executable that's launched.  That leads to JVM version problems for odd people like me whose JAVA_HOME points to a different JDK than the system's default JDK.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:11:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 11 Sep 2006 13:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-311) Use JAVA_HOME in path
 to java executable
In-Reply-To: <18417266.1157994583822.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23954867.1157994703808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-311?page=all ]

Brian Stansberry closed JGRP-311.
---------------------------------

    Resolution: Done

> Use JAVA_HOME in path to java executable
> ----------------------------------------
>
>                 Key: JGRP-311
>                 URL: http://jira.jboss.com/jira/browse/JGRP-311
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3 SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.4
>
>
> In build.bat and build.sh, JAVA_HOME is used in building the classpath but not in creating the path to the java executable that's launched.  That leads to JVM version problems for odd people like me whose JAVA_HOME points to a different JDK than the system's default JDK.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:13:44 2006
From: jira-events at jboss.com (Mauro Lopez (JIRA))
Date: Mon, 11 Sep 2006 13:13:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-344) Portal booking
 example loses conversation after validation error
In-Reply-To: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4347164.1157994824484.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-344?page=comments#action_12343148 ] 
            
Mauro Lopez commented on JBSEAM-344:
------------------------------------

Reproduced also with latest jems installer (jems-installer-1.2.0.BETA2), which bundles JBoss Portal 2.4.0-GA

> Portal booking example loses conversation after validation error
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-344
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Portal
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4.GA
> JBoss Portal 2.4.0-Beta1
> (used jems-installer-1.2.0.BETA)
> JBoss Seam 1.0.1.GA
>            Reporter: Mauro Lopez
>
> Followed this steps:
> - deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
> - Entered http://localhost:8080/portal
> - Selected the SeamHibernate portlet tab, registered user, logged in...
> - Searched hotels, selected one of them, and pressed the "Book" button.
> In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 
> So, after a failed validation, the conversation is lost.
> In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:19:43 2006
From: jira-events at jboss.com (Kerry Barnes (JIRA))
Date: Mon, 11 Sep 2006 13:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3640) Clustering of the
 quartz-ra.rar failes
Message-ID: <21839615.1157995183907.JavaMail.jira@cloud.prod.atl2.jboss.com>

Clustering of the quartz-ra.rar failes
--------------------------------------

                 Key: JBAS-3640
                 URL: http://jira.jboss.com/jira/browse/JBAS-3640
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Clustered JBoss where the Quartz-ra.rar is set up for clustering by using any JDBC DataStore
            Reporter: Kerry Barnes
         Assigned To: Weston Price


When using a JDBC Data Store for the Quarts-ra.rar, the rar fails by indicating that you cannot have a non-volatile trigger associated with a volatile job.

The JobStoreCMT file checks to make sure that if the JobDetail is marked as "volatile" the corresponding Trigger is also marked as "volatile." But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to "true" during construction, but the CronTrigger doesn't supply that option at construction and the default setting is to have the volatility set to "false," which is never changed. A mismatch and a problem

The easiest solution is to modify the JobDetail construction volatility parameter to false so that both instances match. In my tests this generates the desired effect.


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:51:43 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-485) Add "collect"
 conditional element
Message-ID: <7545731.1158000703819.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add "collect" conditional element
---------------------------------

                 Key: JBRULES-485
                 URL: http://jira.jboss.com/jira/browse/JBRULES-485
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: All
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 3.1-m1


Add "collect" conditional element.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:53:43 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-486) Add core and
 compiler support to "collect" conditional element
Message-ID: <30283539.1158000824009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add core and compiler support to "collect" conditional element
--------------------------------------------------------------

                 Key: JBRULES-486
                 URL: http://jira.jboss.com/jira/browse/JBRULES-486
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 3.1-m1


Add support for "collect" conditional element into core and compiler components.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:53:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:53:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-487) Add eclipse plugin
 support for "collect" conditional element
Message-ID: <4117803.1158000824149.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add eclipse plugin support for "collect" conditional element
------------------------------------------------------------

                 Key: JBRULES-487
                 URL: http://jira.jboss.com/jira/browse/JBRULES-487
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Edson Tirelli
             Fix For: 3.1-m1


Add support for "collect" conditional element into eclipse plugin.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:55:43 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-488) Create
 documentation for "collect" conditional element
Message-ID: <27065514.1158000943841.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create documentation for "collect" conditional element
------------------------------------------------------

                 Key: JBRULES-488
                 URL: http://jira.jboss.com/jira/browse/JBRULES-488
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 3.1-m1


Add documentation for "collect" conditional element.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:55:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-487) Add eclipse
 plugin support for "collect" conditional element
In-Reply-To: <4117803.1158000824149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21688286.1158000944042.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-487?page=all ]

Edson Tirelli reassigned JBRULES-487:
-------------------------------------

    Assignee: Kris Verlaenen

> Add eclipse plugin support for "collect" conditional element
> ------------------------------------------------------------
>
>                 Key: JBRULES-487
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-487
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Edson Tirelli
>         Assigned To: Kris Verlaenen
>             Fix For: 3.1-m1
>
>
> Add support for "collect" conditional element into eclipse plugin.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:09:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <461376.1158001784057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Roy Russo reassigned JBPORTAL-1029:
-----------------------------------

    Assignee: Roy Russo  (was: Julien Viet)

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final, 2.6.Alpha1
>            Reporter: Morten Hauch
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:09:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2885841.1158001784213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Roy Russo updated JBPORTAL-1029:
--------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.4.1 Final
          Component/s: Portal Core
                           (was: Portal Portlet)
        Fix Version/s: 2.4.1 Final
    Affects Version/s: 2.6.Alpha1

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final, 2.6.Alpha1
>            Reporter: Morten Hauch
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:41:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 15:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1030) Add support for
 utility region in existing renderers
In-Reply-To: <2242969.1157985343870.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25037607.1158003704248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1030?page=all ]

Roy Russo resolved JBPORTAL-1030.
---------------------------------

    Resolution: Done

Added support for injection of region content, not bound to window fragments.

> Add support for utility region in existing renderers
> ----------------------------------------------------
>
>                 Key: JBPORTAL-1030
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1030
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:51:43 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 11 Sep 2006 15:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3642) Flag an exception in
 CachedConnectionValve if CachedConnectionManager is unavailable
Message-ID: <14004899.1158004303788.JavaMail.jira@cloud.prod.atl2.jboss.com>

Flag an exception in CachedConnectionValve if CachedConnectionManager is unavailable
------------------------------------------------------------------------------------

                 Key: JBAS-3642
                 URL: http://jira.jboss.com/jira/browse/JBAS-3642
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


If the CachedConnectionManager dependency in the Tomcat service is commented out and the CachedConnectionValve is active, there is a NPE.

It is better to throw an RuntimeException suggesting the user as to what needs to be configured (uncomment the CCM dependeny).

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:53:31 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 11 Sep 2006 15:53:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3642) Flag an exception in
 CachedConnectionValve if CachedConnectionManager is unavailable
In-Reply-To: <14004899.1158004303788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21362164.1158004411994.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3642?page=all ]

Anil Saldhana closed JBAS-3642.
-------------------------------

    Resolution: Done

Done.

> Flag an exception in CachedConnectionValve if CachedConnectionManager is unavailable
> ------------------------------------------------------------------------------------
>
>                 Key: JBAS-3642
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3642
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> If the CachedConnectionManager dependency in the Tomcat service is commented out and the CachedConnectionValve is active, there is a NPE.
> It is better to throw an RuntimeException suggesting the user as to what needs to be configured (uncomment the CCM dependeny).

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:03:30 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Mon, 11 Sep 2006 16:03:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31169861.1158005010493.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343157 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

I've completed the first design for the icon based on the new splash screen.

http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm

16 x 16 icon:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside.gif

32 x 32 icon:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside.gif

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:03:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:03:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-625) Embeddable EJB3
 sets up two copies of interceptor declared in ejb-jar.xml
Message-ID: <24984226.1158005010669.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-625?page=all ]

Bill Burke closed EJBTHREE-625.
-------------------------------

    Resolution: Done

> Embeddable EJB3 sets up two copies of interceptor declared in ejb-jar.xml
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-625
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-625
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> My session beans have interceptors attached via:
> <ejb-jar>
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>          <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>       </interceptor-binding>
>    </assembly-descriptor>
> </ejb-jar>
> And (only) when running in embeddable EJB3, they get two instances of SeamInterceptor.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:05:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:05:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-588) Refactor EJB3
 MetaModel and create web.xml/jboss-web.xml metamodel
Message-ID: <31176797.1158005130505.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-588?page=all ]

Bill Burke closed EJBTHREE-588.
-------------------------------

    Resolution: Done

> Refactor EJB3 MetaModel and create web.xml/jboss-web.xml metamodel
> ------------------------------------------------------------------
>
>                 Key: EJBTHREE-588
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-588
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> * refactor all the shared DD elements between ejb-jar.xml and web.xml into their own reusable metamodel. 
> * for now, unless Scott changes, put this new metamodel in jboss-head/j2ee under:
>    org.jboss.metamodel
> * Create a metamodel and XML parsing (the jbossxb shit) for web.xml and jboss-web.xml.  Put this under the jboss-head/tomcat module under
> org.jboss.web.metamodel
> If you can think of a better name for these packages, then do that.
> *DO NOT USE THE OLD WEB.XML SCHEMA!*
> Download the Java EE 5 Servlet specification to obtain the new XML schema for Java EE 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

        


From jira-events at jboss.com  Mon Sep 11 16:07:32 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-217) The container
 should Instruments Hibernate classes
Message-ID: <2459966.1158005252761.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-217?page=all ]

Bill Burke updated EJBTHREE-217:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> The container should Instruments Hibernate classes
> --------------------------------------------------
>
>                 Key: EJBTHREE-217
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-217
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 Beta 1
>            Reporter: Emmanuel Bernard
>         Assigned To: Bill Burke
>            Priority: Minor
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Right now, the user has to instrument Hibernate classes itself through a InstrumentAnt task to enable some features such as property level lazy loading
> It'd be cool if the container execute the same job at class load time in an automatic manner.
> http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#performance-fetching-lazyproperties

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:32 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-197) Deploy Hibernate
 MBean statistics in the EJB 3 Deployer
Message-ID: <23787556.1158005252925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-197?page=all ]

Bill Burke updated EJBTHREE-197:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Deploy Hibernate MBean statistics in the EJB 3 Deployer
> -------------------------------------------------------
>
>                 Key: EJBTHREE-197
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-197
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Michael Yuan
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I discussed this with Emmanuel and Steve over email. They both thought it should be fairly easy to add. The JBoss Network team needs this feature to develop profiling and monitoring tools for EJB 3 (see the linked issue).
> Can we have this feature in the JavaOne release of the product? I can demo it in the trail blazer.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-582)
 Refactoring/implementation of ejb3 sfsb clustering
Message-ID: <32875950.1158005253120.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-582?page=all ]

Bill Burke updated EJBTHREE-582:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Refactoring/implementation of ejb3 sfsb clustering
> --------------------------------------------------
>
>                 Key: EJBTHREE-582
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-582
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This is top level task to track all the tasks related to refactoring and implemntation of current ejb3 sfsb clustering support. Current items include:
> 1. Use JBC to handle passivation
> 2. Make sure straight JBC works with more test cases
> 3. implement fine-grained option

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-402) Remoting proxies
 are not declaring serialVersionUIDs
Message-ID: <32458464.1158005253323.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=all ]

Bill Burke updated EJBTHREE-402:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-477) Implement
 @WebServiceRef and <service-ref>
Message-ID: <31658808.1158005253545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-477?page=all ]

Bill Burke updated EJBTHREE-477:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Implement @WebServiceRef and <service-ref>
> ------------------------------------------
>
>                 Key: EJBTHREE-477
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-477
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This will be fun!!!!
> Take a look at code in EJB 2.1 container.  DO NOT USE THAT CODE DIRECTLY.  I want to start removing dependencies on that code.  You can also work with WS team on this too.  This should be a HIG PRIORITY task.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-466) support
 persistence properties for XML and injection annotations
Message-ID: <32119965.1158005253696.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-466?page=all ]

Bill Burke updated EJBTHREE-466:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> support persistence properties for XML and injection annotations
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-466
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-466
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC5 - PFD
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-344) Deployment should
 fail for resource injection to both field and method
Message-ID: <17879372.1158005253915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-344?page=all ]

Bill Burke updated EJBTHREE-344:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Deployment should fail for resource injection to both field and method
> ----------------------------------------------------------------------
>
>                 Key: EJBTHREE-344
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-344
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: org.jboss.ejb3.test.naming.unit.BadInjectionsUnitTestCase
>            Reporter: Scott M Stark
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I belive the indicated BadInjectionsUnitTestCase should be failing to deploy due to the attempt to inject an env-entry via both a field and method annotation. The ejb-jar.xml key env-entry value is not being injected via either mechanism it appears.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-420) redeploy of
 TreeCached entities fails
Message-ID: <11523404.1158005254142.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-420?page=all ]

Bill Burke updated EJBTHREE-420:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> redeploy of TreeCached entities fails
> -------------------------------------
>
>                 Key: EJBTHREE-420
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-420
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> 2006-01-20 15:14:19,843 INFO  [STDOUT] org.hibernate.PropertyAccessException: exception getting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) getter of com.airit.fidsdb.entity.ArrPrevPortPK.?
>         at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:79)
>         at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:307)
>         at org.hibernate.type.ComponentType.isEqual(ComponentType.java:111)
>         at org.hibernate.cache.CacheKey.equals(CacheKey.java:51)
>         at org.jboss.cache.Fqn.equals(Fqn.java:134)
>         at java.util.HashMap.eq(HashMap.java:277)
>         at java.util.HashMap.containsKey(HashMap.java:346)
>         at org.jboss.cache.eviction.LRUAlgorithm.add(LRUAlgorithm.java:126)
>         at org.jboss.cache.eviction.LRUAlgorithm.processAddedNodes(LRUAlgorithm.java:99)
>         at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:77)
>         at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:52)
>         at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37)
>         at java.util.TimerThread.mainLoop(Timer.java:512)
>         at java.util.TimerThread.run(Timer.java:462)
> Caused by: java.lang.ClassCastException: com.airit.fidsdb.entity.ArrPrevPortPK
>         at com.airit.fidsdb.entity.ArrPrevPortPK$$BulkBeanByCGLIB$$8b6b36b9.getPropertyValues(<generated>)
>         at net.sf.cglib.beans.BulkBean.getPropertyValues(BulkBean.java:48)
>         at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:76)
>         ... 13 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-645) complete
 framework for running standard tests in E-EJB3
Message-ID: <1904401.1158005254276.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-645?page=all ]

Bill Burke updated EJBTHREE-645:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> complete framework for running standard tests in E-EJB3
> -------------------------------------------------------
>
>                 Key: EJBTHREE-645
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-645
>             Project: EJB 3.0
>          Issue Type: Task
>            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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-405) Allow EJB
 Container's ObjectName to be configurable through annotation or XML
Message-ID: <10868811.1158005254717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-405?page=all ]

Bill Burke updated EJBTHREE-405:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Allow EJB Container's ObjectName to be configurable through annotation or XML
> -----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-405
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-405
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-127) Create Docbook
	for @Consumer
Message-ID: <28581077.1158005254915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-127?page=all ]

Bill Burke updated EJBTHREE-127:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Create Docbook for @Consumer
> ----------------------------
>
>                 Key: EJBTHREE-127
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-127
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-525) implement
 <service-ref> in jboss.xml
Message-ID: <4857845.1158005255044.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-525?page=all ]

Bill Burke updated EJBTHREE-525:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> implement <service-ref> in jboss.xml
> ------------------------------------
>
>                 Key: EJBTHREE-525
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-525
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC6 - PFD
>            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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-305) Port EJB 2.1
 tests to EJB 3.0 where appropriate
Message-ID: <5222112.1158005255196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-305?page=all ]

Bill Burke updated EJBTHREE-305:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Port EJB 2.1 tests to EJB 3.0 where appropriate
> -----------------------------------------------
>
>                 Key: EJBTHREE-305
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-305
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC4 - PFD
>            Reporter: Bill Burke
>         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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-672) Use a combination
 of FD and FD_SOCK in the default JGroups protocol stack.
In-Reply-To: <18847956.1154557031452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30909595.1158005255332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-672?page=all ]

Bill Burke updated EJBTHREE-672:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Use a combination of FD and FD_SOCK in the default JGroups protocol stack.
> --------------------------------------------------------------------------
>
>                 Key: EJBTHREE-672
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-672
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same as JBAS-3004.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-585) ejb3 fine-grained
 sfsb replication support
Message-ID: <31994731.1158005255541.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-585?page=all ]

Bill Burke updated EJBTHREE-585:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> ejb3 fine-grained sfsb replication support
> ------------------------------------------
>
>                 Key: EJBTHREE-585
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-585
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This is the parent issue to track the overal fine-grained implementation using PojoCache

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-191) servlet
 initialization happens before EJB startup
Message-ID: <22243525.1158005255664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-191?page=all ]

Bill Burke updated EJBTHREE-191:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> servlet initialization happens before EJB startup
> -------------------------------------------------
>
>                 Key: EJBTHREE-191
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-191
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:37 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-141) Stateful session
 PostConstruct missing transaction, security contexts
Message-ID: <11815339.1158005257920.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-141?page=all ]

Bill Burke updated EJBTHREE-141:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Stateful session PostConstruct missing transaction, security contexts
> ---------------------------------------------------------------------
>
>                 Key: EJBTHREE-141
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-141
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>         Environment: jboss-head
>            Reporter: Jeff Schnitzer
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> While PostConstruct for stateless beans does not run in a transaction or security context, stateful beans are different.  From section 5.1.4.1 "Semantics of the Life Cycle Callback Methods for Stateful Session Beans" of the ejb3-edr2 spec:
> "The PostConstruct method is invoked in the transaction context and security contexts of the first business method on the bean."

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-472) problem with mail
Message-ID: <31624332.1158005258096.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-472?page=all ]

Bill Burke updated EJBTHREE-472:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> problem with mail
> -----------------
>
>                 Key: EJBTHREE-472
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-472
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Bill Burke
>         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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-551) Memory leak in
	EJB3
Message-ID: <16805100.1158005258315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-551?page=all ]

Bill Burke updated EJBTHREE-551:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Memory leak in EJB3
> -------------------
>
>                 Key: EJBTHREE-551
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-551
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Adrian Brock
>             Fix For: EJB 3.0 RC10 - FD
>
>
> See the linked JBossAS Task

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-498) Review duplicate
 security constructs
Message-ID: <28733385.1158005258502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-498?page=all ]

Bill Burke updated EJBTHREE-498:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Review duplicate security constructs
> ------------------------------------
>
>                 Key: EJBTHREE-498
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-498
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Security
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Both ejb3 and aspects/aop have duplicate implementations of JBossSX security constructs that should belong to that project rather than replicated elsewhere. I need to review these and move them into the security project where approriate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-322) implement
	discarding rules
Message-ID: <21931761.1158005258631.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-322?page=all ]

Bill Burke updated EJBTHREE-322:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> implement discarding rules
> --------------------------
>
>                 Key: EJBTHREE-322
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-322
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC1, EJB 3.0 RC2, EJB 3.0 RC3
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> we are not discarding EJB instances where appropriate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-124)
 @PersistenceContext(EXTENDED) should follow new Spec defined rules
Message-ID: <7897902.1158005258755.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-124?page=all ]

Bill Burke updated EJBTHREE-124:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> @PersistenceContext(EXTENDED) should follow new Spec defined rules
> ------------------------------------------------------------------
>
>                 Key: EJBTHREE-124
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-124
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: Preview 5
>            Reporter: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I don't yet follow all the spec defined rules for @PersistenceContext(EXTENDED)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-342) Unify
 configuration file names and bootstrap
Message-ID: <11969392.1158005258955.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-342?page=all ]

Bill Burke updated EJBTHREE-342:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Unify configuration file names and bootstrap
> --------------------------------------------
>
>                 Key: EJBTHREE-342
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-342
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Christian Bauer
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> The microcontainer can be booted with StandaloneBootstrap, and it searches for jboss-beans.xml in / and META-INF.
> The E-EJB3 container is booted with EJB3StandaloneBootstrap, which searches for embedded-jboss-beans.xml in / and supports a "basepath" argument.
> Unify these two bootstrap classes. Wishlist:
> - sensible default name for the configuration file ("jboss-beans.xml" sounds good)
> - searches in default locations (/ and META-INF)
> - supports parameters to completely override not only the "basepath", but the full location of the configuration file
> The EJB3StandaloneBootstrap should _extend_ the StandaloneBootstrap, not reimplement it. The current situation makes documentation and explanation unecessarily difficult.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:39 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-564) Inconsistent
 results in ConsumerUnitTestCase
Message-ID: <18256075.1158005259208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-564?page=all ]

Bill Burke updated EJBTHREE-564:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Inconsistent results in ConsumerUnitTestCase
> --------------------------------------------
>
>                 Key: EJBTHREE-564
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-564
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>            Reporter: Scott M Stark
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC10 - FD
>
>
> If I run the ConsumerUnitTestCase multiple times I start seeing failures due to method invocation order it seems.
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>     [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 16.344 sec
> BUILD SUCCESSFUL
> Total time: 21 seconds
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>     [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 14.359 sec
>     [junit] Test org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase FAILED
> BUILD SUCCESSFUL
> Total time: 19 seconds
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>     [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 14.86 sec
>     [junit] Test org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase FAILED
> BUILD SUCCESSFUL
> Total time: 19 seconds
>   <testcase classname="org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase" name="testDeploymentDescriptorQueueXA" time="2.032">
>     <failure message="expected:&lt;...1&gt; but was:&lt;...2&gt;" type="junit.framework.ComparisonFailure">junit.framework.ComparisonFailure: expected:&lt;...1&gt; but was:&lt;...2&gt;
> 	at org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase.testDeploymentDescriptorQueueXA(ConsumerUnitTestCase.java:151)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> </failure>

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:40 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-372) MDB Management
	features
Message-ID: <20023022.1158005260029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-372?page=all ]

Bill Burke updated EJBTHREE-372:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> MDB Management features
> -----------------------
>
>                 Key: EJBTHREE-372
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-372
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Kabir Khan
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Implement startDelivery(), stopDelivery(), setMaxMessages(int) and adjust the MDB pool size for MDBs

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:40 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-575) Access
 configuration attributes through JMX
Message-ID: <1429039.1158005260152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-575?page=all ]

Bill Burke updated EJBTHREE-575:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Access configuration attributes through JMX
> -------------------------------------------
>
>                 Key: EJBTHREE-575
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-575
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Darran Lofthouse
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This might be more appropriate split into a number of tasks but for the moment I am raising it as a single issue.
> There are a number of properties that can be set on message driven beans using activation config properties e.g. 'maxPoolSize'.  After deployment there is not a mechanism to check that the correct properties have been applied.  It would be good to be able to inspect the configuration values using JMX.
> Using the @PoolClass annotation it is possible to configure the pool that is used for the EJB, it would also be good if this configuration information could also be made available using JMX.
> For the configuration items it would also be good if the attributes could be updated using JMX.
> Finally providing status information such as current pool sizes through JMX would also help users check the configuration they have selected is appropriate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:40 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-27) Allowed methods
Message-ID: <31773060.1158005260850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-27?page=all ]

Bill Burke updated EJBTHREE-27:
-------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Allowed methods
> ---------------
>
>                 Key: EJBTHREE-27
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-27
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: Preview 5
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> EJB specification has semanatics for what methods can be called when.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:41 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-421) Put
 FlushMode.NEVER back on
 track through @FlushMode, at least in a proprietary manner
Message-ID: <22367258.1158005261038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-421?page=all ]

Bill Burke updated EJBTHREE-421:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Put FlushMode.NEVER back on track through @FlushMode, at least in a proprietary manner
> --------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-421
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-421
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Emmanuel Bernard
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:41 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-414) Support Nested
 SFSB in clustered environment
Message-ID: <651104.1158005261288.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-414?page=all ]

Bill Burke updated EJBTHREE-414:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Support Nested SFSB in clustered environment
> --------------------------------------------
>
>                 Key: EJBTHREE-414
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-414
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:41 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-12) EJB ENC must be
 java:comp/env currently it is java.ejb/comp/env
Message-ID: <6915320.1158005261503.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-12?page=all ]

Bill Burke updated EJBTHREE-12:
-------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> EJB ENC must be java:comp/env  currently it is java.ejb/comp/env
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-12
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-12
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: Preview 5
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:09:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-212) Support
	servlet/jsp injection
Message-ID: <26962743.1158005370570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke closed EJBTHREE-212.
-------------------------------

    Resolution: Done

This works ONLY in HEAD.  JSP injection not working yet.  Requires some changes to Tomcat.

> Support servlet/jsp injection
> -----------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:09:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-212) Support
	servlet/jsp injection
Message-ID: <30166601.1158005370862.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke reopened EJBTHREE-212:
---------------------------------

             

> Support servlet/jsp injection
> -----------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:09:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-212) Support servlet
	injection
Message-ID: <3097357.1158005371144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke updated EJBTHREE-212:
--------------------------------

    Summary: Support servlet injection  (was: Support servlet/jsp injection)

create JSP task in different task

> Support servlet injection
> -------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:09:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-212) Support servlet
	injection
Message-ID: <10627374.1158005371427.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke closed EJBTHREE-212.
-------------------------------

    Resolution: Done

> Support servlet injection
> -------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:11:29 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-687)
	EntityManager.getDelegate()
In-Reply-To: <15751408.1155655220332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19246799.1158005489946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-687?page=all ]

Bill Burke updated EJBTHREE-687:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> EntityManager.getDelegate()
> ---------------------------
>
>                 Key: EJBTHREE-687
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-687
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Emmanuel Bernard
>             Fix For: EJB 3.0 RC10 - FD
>
>
> EntityManager.getdelegate() currently returns the underlying entityManager (let's say HibernateEntityManager)
> It is more convinient and coherence between SE and EE to return hibernateEntityManager.getDelegate() rather than hibernate EntityManager

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:13:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-509) EJB 3.0
 persistense manager
 unit name is not comming up when deploying entity bean
Message-ID: <21911233.1158005611705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-509?page=all ]

Bill Burke updated EJBTHREE-509:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> EJB 3.0 persistense manager unit name is not comming up when deploying entity bean
> ----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-509
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-509
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC5 - PFD
>         Environment: linux, jboss 4.0.2
>            Reporter: Amit Chauhan
>            Priority: Minor
>             Fix For: EJB 3.0 RC10 - FD
>
>
> trying to implement the tutorial example provided at http://docs.jboss.org/ejb3/app-servers/tutorials/entity/entity.html

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:13:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-661) Security:
 Deploying a bean
 without mandatory org.jboss.ejb3.security.SecurityDomain results in a
 NullPointerException
In-Reply-To: <7251726.1153836311374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2340557.1158005611835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-661?page=all ]

Bill Burke updated EJBTHREE-661:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Security: Deploying a bean without mandatory org.jboss.ejb3.security.SecurityDomain results in a NullPointerException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-661
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-661
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>             Fix For: EJB 3.0 RC10 - FD
>
>
> When setting up security in a EJB3 bean, it is mandatory adding the 
> org.jboss.ejb3.security.SecurityDomain tag. Failure to do so results 
> on a NullPointerException. 
> AS should log a more meaningful message rather than a 
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:21:30 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 11 Sep 2006 16:21:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-658) @Resources at
 class level does not create correct local jndi binding
In-Reply-To: <29222280.1153431671371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21627034.1158006090850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-658?page=all ]

William DeCoste closed EJBTHREE-658.
------------------------------------

    Resolution: Done

> @Resources at class level does not create correct local jndi binding
> --------------------------------------------------------------------
>
>                 Key: EJBTHREE-658
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-658
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - 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

        


From jira-events at jboss.com  Mon Sep 11 16:27:32 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Mon, 11 Sep 2006 16:27:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5545432.1158006452562.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343160 ] 
            
Marshall Culpepper commented on JBIDE-354:
------------------------------------------

Hey James..

These icons seem a little 2-tone... not a whole lot of color. I'm guessing you're working with the limitations of the GIF colorspace and replicating the eclipse effect from your new splash.. Do you think instead of pulling from the new splash screen we should start with something fresh for the smaller icons?

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 17:09:30 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 11 Sep 2006 17:09:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-307) Run testsuite in
	Fedore Core 3
In-Reply-To: <9618913.1157811463886.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23375939.1158008970969.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-307?page=all ]

Bela Ban resolved JGRP-307.
---------------------------

    Resolution: Done

runs for me

> Run testsuite in Fedore Core 3
> ------------------------------
>
>                 Key: JGRP-307
>                 URL: http://jira.jboss.com/jira/browse/JGRP-307
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Optional
>             Fix For: 2.4
>
>
> A user reported some failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 17:19:30 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 17:19:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1032) Document
 NavigationPortlet new features
Message-ID: <1491958.1158009570281.JavaMail.jira@cloud.prod.atl2.jboss.com>

Document NavigationPortlet new features
---------------------------------------

                 Key: JBPORTAL-1032
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1032
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


1. excplitict tab ordering
2. localization 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

        


From jira-events at jboss.com  Mon Sep 11 17:27:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 17:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1025) Integrate new
 theme with portal codebase
In-Reply-To: <22595979.1157647004438.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15833922.1158010049462.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1025?page=all ]

Roy Russo resolved JBPORTAL-1025.
---------------------------------

    Resolution: Done

> Integrate new theme with portal codebase
> ----------------------------------------
>
>                 Key: JBPORTAL-1025
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1025
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 17:27:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 17:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-989) Create new
	Default Theme
In-Reply-To: <30876246.1156181504563.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21098707.1158010049570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-989?page=all ]

Roy Russo resolved JBPORTAL-989.
--------------------------------

    Resolution: Done

> Create new Default Theme
> ------------------------
>
>                 Key: JBPORTAL-989
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-989
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Use mockup v3 to generate CSS theme.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 18:27:30 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Mon, 11 Sep 2006 18:27:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3658863.1158013650477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343165 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

___________________________________________________________________________

I've reworked the graphics to be more colorful. I still stayed wlth the "eclipse" because that seems themost appropriate. 


http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm


16 x 16
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside.gif

32 x 32
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside.gif



> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 18:59:29 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 18:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
Message-ID: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>

Closing connection inside MessageListener's onMessage() causes deadlock
-----------------------------------------------------------------------

                 Key: JBMESSAGING-542
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.0.1.CR5, 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep 11 19:41:29 2006
From: jira-events at jboss.com (Edward Lu (JIRA))
Date: Mon, 11 Sep 2006 19:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3643) null message blob is
 created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
Message-ID: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>

null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
-----------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3643
                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Windows XP, Oracle 9.2.0.5
            Reporter: Edward Lu
         Assigned To: Adrian Brock
            Priority: Critical


A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):

I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.

Your help is highly appreciated.

****************************************************************************************
SQL> select count(*) from jms_messages where messageblob is null;

  COUNT(*)
----------
         3

*******************************************************************************************
2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
(java.lang.NullPointerException)^M
        at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
        at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
        at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
        at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M

......
......

Caused by: java.lang.NullPointerException^M
        at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
        at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
        at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
        at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
        at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M

*******************************************************************************************************************



-- 
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

        


From jira-events at jboss.com  Mon Sep 11 20:37:31 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 20:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7779673.1158021451334.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=comments#action_12343169 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-542:
---------------------------------------------

Paliative fix:

      if (Thread.currentThread().equals(sessionExecutor.getThread()))
      {
         // the current thread already closing this MessageCallbackHandler, so no need to register
         // another Closer (see http://jira.jboss.org/jira/browse/JBMESSAGING-542)
         return;
      }

in MessageCallbackHandler.waitForOnMessageToComplete()

However, if we allow the listener to close the connection within onMessage(), then postDeliver() won't be able to pass by session's ClosedInterceptor, which now is "closed", so we'll get an ERROR "Failed to deliver message" in the logs. It's harmless, but ugly. 

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 20:39:29 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 20:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14853800.1158021569970.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov updated JBMESSAGING-542:
----------------------------------------

    Comment: was deleted

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 20:39:30 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 20:39:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25432712.1158021570083.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=comments#action_12343170 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-542:
---------------------------------------------

Palliative fix:

      if (Thread.currentThread().equals(sessionExecutor.getThread()))
      {
         return;
      }

in MessageCallbackHandler.waitForOnMessageToComplete()

However, if we allow the listener to close the connection within onMessage(), then postDeliver() won't be able to pass by session's ClosedInterceptor, which now is "closed", so we'll get an ERROR "Failed to deliver message" in the logs. It's harmless, but ugly.

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 03:09:32 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Tue, 12 Sep 2006 03:09:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-211) update user guide to
 include new features
In-Reply-To: <24593365.1157241343825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21628852.1158044972483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-211?page=all ]

Alejandro Guizar resolved BPEL-211.
-----------------------------------

    Resolution: Done

Moved examples each to a separate chapter.

> update user guide to include new features
> -----------------------------------------
>
>                 Key: BPEL-211
>                 URL: http://jira.jboss.com/jira/browse/BPEL-211
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>
> -Describe the simplified deployment process
> -Document time-driven activities

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 04:15:31 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Tue, 12 Sep 2006 04:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-193) template for new
	projects
Message-ID: <15414913.1158048931430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-193?page=all ]

Alejandro Guizar updated BPEL-193:
----------------------------------

    Fix Version/s:     (was: jBPM BPEL 1.1 beta 2)
                   jBPM BPEL 1.1 beta 3

> template for new projects
> -------------------------
>
>                 Key: BPEL-193
>                 URL: http://jira.jboss.com/jira/browse/BPEL-193
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 3
>
>
> Burr Sutter wrote:
> "I was only hoping for an easy way to build, modify and redeploy HelloWorld or ATM with the least amount of effort.  Something like
> 1. Edit BPEL file
> 2. Deploy
> 3. In the browser view the WSDL
> Having Ant tasks that make it this easy and a template project and build script for getting started would be great for the first release of our BPEL engine."

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:25:40 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 12 Sep 2006 05:25:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
Message-ID: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>

Transaction rollback does not restore contents of collection of cached collections
----------------------------------------------------------------------------------

                 Key: JBCACHE-763
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Nitzan Niv
         Assigned To: Manik Surtani


In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.

1. create 2 "data elements" in the cache which are Map instances.
2. create a "data elements container" in the cache which is a Map instance.
3. initalize the container with one data element.
4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.

After the rollback the element in the container is neither the new data element nor the old data element.

It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:32:43 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 12 Sep 2006 05:32:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-149) Singleton
 failover based on rules
Message-ID: <32376301.1158053564005.JavaMail.jira@cloud.prod.atl2.jboss.com>

Singleton failover based on rules
---------------------------------

                 Key: JBCLUSTER-149
                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-149
             Project: JBoss Clustering
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry


I think that clustering (in this case clustered Singletons) are missing this kind of features. For instance, It would be nice if I had an API where I could:
- Ask the status of each node on the partition (CPU usage, mem usage,...). (This can be done today ...)
- With the data previously collected, my Singleton could decide: Now I wan't to migrate to nobe B because it is with no CPU usage, or because...

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:34:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 12 Sep 2006 05:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2922421.1158053683917.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Nitzan Niv updated JBCACHE-763:
-------------------------------

    Attachment: PojoCollectionRollbackTest.java

test case attached

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:34:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 05:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-764) Update docs,
 examples and tutorial to reflect 2.0.0 API
Message-ID: <29600380.1158053683994.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update docs, examples and tutorial to reflect 2.0.0 API
-------------------------------------------------------

                 Key: JBCACHE-764
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-764
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.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

        


From jira-events at jboss.com  Tue Sep 12 05:36:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 05:36:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCLUSTER-149) Singleton
 failover based on rules
In-Reply-To: <32376301.1158053564005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6709731.1158053803872.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-149?page=all ]

Dimitris Andreadis closed JBCLUSTER-149.
----------------------------------------

    Resolution: Duplicate Issue

See JBAS-3636

> Singleton failover based on rules
> ---------------------------------
>
>                 Key: JBCLUSTER-149
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-149
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>
> I think that clustering (in this case clustered Singletons) are missing this kind of features. For instance, It would be nice if I had an API where I could:
> - Ask the status of each node on the partition (CPU usage, mem usage,...). (This can be done today ...)
> - With the data previously collected, my Singleton could decide: Now I wan't to migrate to nobe B because it is with no CPU usage, or because...

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:40:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 12 Sep 2006 05:40:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3643) null message blob is
 created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
In-Reply-To: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24074493.1158054043848.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3643?page=all ]

Adrian Brock closed JBAS-3643.
------------------------------

      Assignee:     (was: Adrian Brock)
    Resolution: Duplicate Issue

> null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Windows XP, Oracle 9.2.0.5
>            Reporter: Edward Lu
>            Priority: Critical
>
> A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):
> I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.
> Your help is highly appreciated.
> ****************************************************************************************
> SQL> select count(*) from jms_messages where messageblob is null;
>   COUNT(*)
> ----------
>          3
> *******************************************************************************************
> 2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
> org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
> (java.lang.NullPointerException)^M
>         at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
>         at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
>         at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
>         at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M
> ......
> ......
> Caused by: java.lang.NullPointerException^M
>         at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
>         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
>         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
>         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
>         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M
> *******************************************************************************************************************

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 06:02:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 06:02:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31731840.1158055363927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Manik Surtani reassigned JBCACHE-763:
-------------------------------------

    Assignee: Ben Wang  (was: Manik Surtani)

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 06:05:34 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 12 Sep 2006 06:05:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-149) Singleton
 failover based on rules
In-Reply-To: <32376301.1158053564005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18155867.1158055534015.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-149?page=comments#action_12343176 ] 
            
Galder Zamarreno commented on JBCLUSTER-149:
--------------------------------------------

Oops, I missed that one :-)

Thanks

Galder Zamarre?o
Support Engineer
JBoss, a division of Red Hat




> Singleton failover based on rules
> ---------------------------------
>
>                 Key: JBCLUSTER-149
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-149
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>
> I think that clustering (in this case clustered Singletons) are missing this kind of features. For instance, It would be nice if I had an API where I could:
> - Ask the status of each node on the partition (CPU usage, mem usage,...). (This can be done today ...)
> - With the data previously collected, my Singleton could decide: Now I wan't to migrate to nobe B because it is with no CPU usage, or because...

-- 
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

       



From jira-events at jboss.com  Tue Sep 12 07:11:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Tue, 12 Sep 2006 07:11:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-312) Make testsuite
 configurable to run with different stack configurations
Message-ID: <23960957.1158059494513.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make testsuite configurable to run with different stack configurations
----------------------------------------------------------------------

                 Key: JGRP-312
                 URL: http://jira.jboss.com/jira/browse/JGRP-312
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


All test programs should use a system property (with a default if the system property is not defined). The testsuite can then be run with the system property, so all tests use TCP, for example.
We could also use multiple targets, one for each major stack configuration. An 'all-unittests' target would run all of them.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 07:25:35 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 07:25:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3602) 3 failing tests
 org.jboss.test.jacc.test (jrockit)
In-Reply-To: <18072439.1157132983856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19277784.1158060335880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3602?page=all ]

Dimitris Andreadis closed JBAS-3602.
------------------------------------

         Assignee: Dimitris Andreadis  (was: Anil Saldhana)
    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Fixed

> 3 failing tests org.jboss.test.jacc.test (jrockit)
> --------------------------------------------------
>
>                 Key: JBAS-3602
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3602
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> org.jboss.test.jacc.test
> EJBSpecUnitTestCase(JACC)
> EJBSpecUnitTestCase(JACC+SecurityMgr) 
> testStressNoJaasCache Failure Thread error count == 0
> junit.framework.AssertionFailedError: Thread error count == 0
> 	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStress(EJBSpecUnitTestCase.java:822)
> 	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStressNoJaasCache(EJBSpecUnitTestCase.java:842)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> testGetCallerPrincipal Failure Was able to call StatelessSession.echo
> junit.framework.AssertionFailedError: Was able to call StatelessSession.echo
> 	at org.jboss.test.security.test.EJBSpecUnitTestCase.testGetCallerPrincipal(EJBSpecUnitTestCase.java:194)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 07:37:36 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 07:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3606) failed
 org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
In-Reply-To: <4834417.1157135743871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33350811.1158061056083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3606?page=all ]

Dimitris Andreadis closed JBAS-3606.
------------------------------------

       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Anil Saldhana)
    Fix Version/s: JBossAS-5.0.0.Beta

Fixed

> failed org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
> ----------------------------------------------------------------
>
>                 Key: JBAS-3606
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3606
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testSecureHttpInvokerFailure Failure
> Should not have been able to lookup(jmx)
> junit.framework.AssertionFailedError: Should not have been able to lookup(jmx)
> 	at org.jboss.test.naming.test.SecurityUnitTestCase.testSecureHttpInvokerFailure(SecurityUnitTestCase.java:77)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Tue Sep 12 07:49:39 2006
From: jira-events at jboss.com (Lubos Lipinsky (JIRA))
Date: Tue, 12 Sep 2006 07:49:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (HIBERNATE-14) Support for
 loading annotations in HAR
Message-ID: <31635403.1158061779079.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/HIBERNATE-14?page=comments#action_12343179 ] 
            
Lubos Lipinsky commented on HIBERNATE-14:
-----------------------------------------

I think this feature is very easy to implement and would help many developers to simplify configuration files maintenance. Why it was removed from all versions?

> Support for loading annotations in HAR
> --------------------------------------
>
>                 Key: HIBERNATE-14
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-14
>             Project: Hibernate
>          Issue Type: Feature Request
>            Reporter: youngm
>         Assigned To: Gavin King
>
> It would be nice to have annotations support for HAR deployments.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:06:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3607) failing
 org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
In-Reply-To: <24350644.1157135863866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24984789.1158062793548.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3607?page=all ]

Dimitris Andreadis closed JBAS-3607.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Scott M Stark)

Fixed

> failing org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
> -------------------------------------------------------------------
>
>                 Key: JBAS-3607
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3607
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testEjbRemoveNotCalledForEveryCall Failure
> createCounter expected:<1> but was:<0>
> junit.framework.AssertionFailedError: createCounter expected:<1> but was:<0>
> 	at org.jboss.test.session.test.EjbRemoveUnitTestCase.testEjbRemoveNotCalledForEveryCall(EjbRemoveUnitTestCase.java:96)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:10:37 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Tue, 12 Sep 2006 08:10:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-486) Add core and
 compiler support to "collect" conditional element
In-Reply-To: <30283539.1158000824009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26813212.1158063037513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-486?page=all ]

Edson Tirelli resolved JBRULES-486.
-----------------------------------

    Resolution: Done

Support implemented and added to trunk in revision #6167:

----------------
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParser.java
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParserLexer.java
Adding         drools-compiler/src/main/java/org/drools/lang/descr/CollectDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/DescrFactory.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/lang/drl.g
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/lang/RuleParserTest.java
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_Collect.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/collect.drl
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Adding         drools-core/src/main/java/org/drools/reteoo/CollectNode.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteooBuilder.java
Adding         drools-core/src/main/java/org/drools/rule/Collect.java
Sending        drools-core/src/main/java/org/drools/rule/Rule.java
Adding         drools-core/src/test/java/org/drools/reteoo/CollectNodeTest.java
Transmitting file data .................
Committed revision 6167.
---------------------

> Add core and compiler support to "collect" conditional element
> --------------------------------------------------------------
>
>                 Key: JBRULES-486
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-486
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>
> Add support for "collect" conditional element into core and compiler components.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:12:30 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Tue, 12 Sep 2006 08:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-487) Add eclipse
 plugin support for "collect" conditional element
In-Reply-To: <4117803.1158000824149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2805394.1158063150972.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-487?page=comments#action_12343182 ] 
            
Edson Tirelli commented on JBRULES-487:
---------------------------------------

Kris, support for collect in core and compiler was commited in revision #6167.

There is an integration test you can use:  test_Collect.drl.


> Add eclipse plugin support for "collect" conditional element
> ------------------------------------------------------------
>
>                 Key: JBRULES-487
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-487
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Edson Tirelli
>         Assigned To: Kris Verlaenen
>             Fix For: 3.1-m1
>
>
> Add support for "collect" conditional element into eclipse plugin.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:18:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3608) 2 failing tests
 org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
In-Reply-To: <3989808.1157135983973.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24423918.1158063509723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3608?page=all ]

Dimitris Andreadis closed JBAS-3608.
------------------------------------

         Assignee: Dimitris Andreadis  (was: Thomas Diesler)
    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Fixed

> 2 failing tests org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3608
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testHandlerFlowServerReturn Failure
> testHandlerFlowAllPass Failure
> Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
> junit.framework.AssertionFailedError: Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
> 	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.assertHandlerProtocol(HandlerFlowTestCase.java:140)
> 	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.testHandlerFlowServerReturn(HandlerFlowTestCase.java:134)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:24:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3609) failing
 org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
In-Reply-To: <23815383.1157135984122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19206095.1158063869987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3609?page=all ]

Dimitris Andreadis closed JBAS-3609.
------------------------------------

       Resolution: Done
    Fix Version/s: JBossAS-5.0.0.Beta
         Assignee: Dimitris Andreadis  (was: Thomas Diesler)

Fixed

> failing org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
> -----------------------------------------------------------------
>
>                 Key: JBAS-3609
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3609
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testGetVersion Failure
> expected:<Version-1.0> but was:<null>
> junit.framework.ComparisonFailure: expected:<Version-1.0> but was:<null>
> 	at org.jboss.test.webservice.jbws70.JBWS70TestCase.testGetVersion(JBWS70TestCase.java:74)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:44:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:44:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3610) failing
 org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl)
 (jrockit)
In-Reply-To: <768700.1157136823860.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1344727.1158065071473.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3610?page=all ]

Dimitris Andreadis closed JBAS-3610.
------------------------------------

         Assignee: Dimitris Andreadis  (was: Thomas Diesler)
    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Done

Fixed

> failing org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl) (jrockit)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3610
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3610
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>
> testWithTransportOptions Error
> Call invocation failed: Could not transmit message; nested exception is: javax.xml.soap.SOAPException: Could not transmit message
> java.rmi.RemoteException: Call invocation failed: Could not transmit message; nested exception is: 
> 	javax.xml.soap.SOAPException: Could not transmit message
> 	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:718)
> 	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
> 	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
> 	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
> 	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: javax.xml.soap.SOAPException: Could not transmit message
> 	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:204)
> 	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
> 	... 23 more
> Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
> 	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
> 	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
> 	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
> 	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
> 	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
> 	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(BLjava.lang.Throwable;Ljava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(BLjava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush()V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_bc;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_az.j()V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_ba;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(BI)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j()V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake()V(DashoA12275:???)
> 	at sun.net.www.protocol.https.HttpsClient.afterConnect()V(DashoA12275:???)
> 	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect()V(DashoA12275:???)
> 	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:569)
> 	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream()Ljava.io.OutputStream;(DashoA12275:???)
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:163)
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
>  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:44:31 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 12 Sep 2006 08:44:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-749) extra configuration
 parameters for jbpm thread servlet
Message-ID: <9684337.1158065071611.JavaMail.jira@cloud.prod.atl2.jboss.com>

extra configuration parameters for jbpm thread servlet
------------------------------------------------------

                 Key: JBPM-749
                 URL: http://jira.jboss.com/jira/browse/JBPM-749
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3


Following servlet init configuration parameters are added to the JbpmThreadServlet:

commandExecutorInterval: time in milliseconds between two subsequent checks for messages by the command executor thread.  default is 5000.

schedulerInterval: time in milliseconds between two subsequent checks for timers by the scheduler thread.  default is 5000.

priority: priority of the command executor and scheduler threads. default is 1.

maxResultCount: max number of timers processed per transaction.  default is 1.



-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:54:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 12 Sep 2006 08:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-749) extra configuration
 parameters for jbpm thread servlet
In-Reply-To: <9684337.1158065071611.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20168580.1158065672520.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-749?page=all ]

Tom Baeyens updated JBPM-749:
-----------------------------

    Attachment: jbpm-3.1.3-snapshot.jar

added a jbpm lib, which is a snapshot build inbetween 3.1.2 and the upcoming 3.1.3.  it includes these extra configuration parameters.  please, let us know if you you are able to try this out and give us some feedback.

> extra configuration parameters for jbpm thread servlet
> ------------------------------------------------------
>
>                 Key: JBPM-749
>                 URL: http://jira.jboss.com/jira/browse/JBPM-749
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3
>
>         Attachments: jbpm-3.1.3-snapshot.jar
>
>
> Following servlet init configuration parameters are added to the JbpmThreadServlet:
> commandExecutorInterval: time in milliseconds between two subsequent checks for messages by the command executor thread.  default is 5000.
> schedulerInterval: time in milliseconds between two subsequent checks for timers by the scheduler thread.  default is 5000.
> priority: priority of the command executor and scheduler threads. default is 1.
> maxResultCount: max number of timers processed per transaction.  default is 1.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:54:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 12 Sep 2006 08:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-749) extra configuration
 parameters for jbpm thread servlet
In-Reply-To: <9684337.1158065071611.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13203890.1158065672689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-749?page=all ]

Tom Baeyens closed JBPM-749.
----------------------------

    Resolution: Done

> extra configuration parameters for jbpm thread servlet
> ------------------------------------------------------
>
>                 Key: JBPM-749
>                 URL: http://jira.jboss.com/jira/browse/JBPM-749
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3
>
>         Attachments: jbpm-3.1.3-snapshot.jar
>
>
> Following servlet init configuration parameters are added to the JbpmThreadServlet:
> commandExecutorInterval: time in milliseconds between two subsequent checks for messages by the command executor thread.  default is 5000.
> schedulerInterval: time in milliseconds between two subsequent checks for timers by the scheduler thread.  default is 5000.
> priority: priority of the command executor and scheduler threads. default is 1.
> maxResultCount: max number of timers processed per transaction.  default is 1.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:56:34 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 08:56:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-434) InternalDelegate
 doesn't relocate AOP nodes properly
Message-ID: <27446258.1158065794106.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ]

Ben Wang resolved JBCACHE-434.
------------------------------

    Resolution: Out of Date

Since PojoCache object mapping has been refactored in 2.0, this issue should not relevant anymore.

> InternalDelegate doesn't relocate AOP nodes properly
> ----------------------------------------------------
>
>                 Key: JBCACHE-434
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-434
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: twundke
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: relocate.txt
>
>
> When the object graph handler attempts to remove a node that has references to it, it relocates the data to the first referencing FQN in the list. However, InternalDelegate.relocate() fails to correctly update the AOP references. There is some commented-out code that seems to attempt to update the indirect FQN.
> I've attatched my updated code (for our demo), but it's overly complicated due to lack of time, sleep etc. In fact it fully updates the internal state of the cache for the node (including changing the indirect FQN, and changing all references to point to the new indirect FQN), which was the quickest way to get a solution at the time. You can probably cut out half of this by simply updating the indirect FQN correctly, which I presume was the intent in the first place. However, I believe this still only half-solves the problem as the reference counts need to be updated.
> Sorry if this is a bit of a vague bug report Ben, but I can't fully remember my thinking at the time. Hopefully my code at least shows all that has to be done to keep the cache consistent.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 09:00:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Tue, 12 Sep 2006 09:00:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-303) Verify that all
 synchronized statements have short scopes
In-Reply-To: <292182.1157790209387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15295867.1158066033267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-303?page=all ]

Bela Ban updated JGRP-303:
--------------------------

    Fix Version/s:     (was: 2.4)
                   2.5

> 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.5
>
>
> 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

        


From jira-events at jboss.com  Tue Sep 12 09:02:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Tue, 12 Sep 2006 09:02:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-313) MultiplexerTests
 don't work with TCP configuration
Message-ID: <15805211.1158066153671.JavaMail.jira@cloud.prod.atl2.jboss.com>

MultiplexerTests don't work with TCP configuration
--------------------------------------------------

                 Key: JGRP-313
                 URL: http://jira.jboss.com/jira/browse/JGRP-313
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


UDP works 100%, however, some of the tests fail with a TCP configuration

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:39:36 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 12 Sep 2006 11:39:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-765) implementation of
 equals() in collections is incorrect
Message-ID: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>

implementation of equals() in collections is incorrect
------------------------------------------------------

                 Key: JBCACHE-765
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Nitzan Niv
         Assigned To: Ben Wang


The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).



-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:41:39 2006
From: jira-events at jboss.com (Arik Kfir (JIRA))
Date: Tue, 12 Sep 2006 11:41:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-661) Security:
 Deploying a bean
 without mandatory org.jboss.ejb3.security.SecurityDomain results in a
 NullPointerException
In-Reply-To: <7251726.1153836311374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18715455.1158075699713.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-661?page=comments#action_12343193 ] 
            
Arik Kfir commented on EJBTHREE-661:
------------------------------------

Did you try setting it in the ejb-jar's jboss.xml descriptor? 

> Security: Deploying a bean without mandatory org.jboss.ejb3.security.SecurityDomain results in a NullPointerException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-661
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-661
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>             Fix For: EJB 3.0 RC10 - FD
>
>
> When setting up security in a EJB3 bean, it is mandatory adding the 
> org.jboss.ejb3.security.SecurityDomain tag. Failure to do so results 
> on a NullPointerException. 
> AS should log a more meaningful message rather than a 
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:46:34 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 12 Sep 2006 11:46:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-489) Category to have
 seperate "add" method (not getOrCreateCategory)
Message-ID: <14203982.1158075994710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Category to have seperate "add" method (not getOrCreateCategory)
----------------------------------------------------------------

                 Key: JBRULES-489
                 URL: http://jira.jboss.com/jira/browse/JBRULES-489
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:48:37 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 12 Sep 2006 11:48:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-489) Category to have
 seperate "add" method (not getOrCreateCategory)
In-Reply-To: <14203982.1158075994710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22247034.1158076117159.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-489?page=comments#action_12343194 ] 
            
Michael Neale commented on JBRULES-489:
---------------------------------------

perhaps its better to have category added seperately (plus category will have meta data like description).

> Category to have seperate "add" method (not getOrCreateCategory)
> ----------------------------------------------------------------
>
>                 Key: JBRULES-489
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-489
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:48:37 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 11:48:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-4) Evaluate OpenDS
 (Sun's OSS all-java Directory Server)
Message-ID: <3697073.1158076117046.JavaMail.jira@cloud.prod.atl2.jboss.com>

Evaluate OpenDS (Sun's OSS all-java Directory Server)
-----------------------------------------------------

                 Key: SECURITY-4
                 URL: http://jira.jboss.com/jira/browse/SECURITY-4
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Anil Saldhana
         Assigned To: Scott M Stark


https://opends.dev.java.net/public/docs/OpenDS-FAQ.html

- Requires JDK5. 
- Java only.
- Ldif import/export supported.

Good candidate for HEAD testsuite integration.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:41:40 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 12:41:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
Message-ID: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>

Don't return unnecessary values from _replicate, avoiding need for marshalling
------------------------------------------------------------------------------

                 Key: JBCACHE-766
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
             Project: JBoss Cache
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani
            Priority: Minor
             Fix For: 1.4.0.SP2


This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
responses passed over RpcDispatcher as well as for requests, but is a simpler and
less general fix.

Right now if you set a class loader for a tree cache region, it works for request parameters,
but is ignored for returns. If there is an attempt to return a value that needs to be loaded
with the class loader, an exception will be thrown.

The only return value in normal REPL_SYNC operation is the return value from 
the key-value put methods, which is the old value, if any. But that return value isn't
needed for replication. So, this patch just nulls out the return value from the two affected
methods.

(We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
entities are stored directly in the cache, and are serialized/deserialized on replication.
There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
hacky manner.)



-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:43:32 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 12:43:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-756) Marshaller
 breaks with Strings of length greater than 32767
In-Reply-To: <28986578.1156934144423.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25000128.1158079412860.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-756?page=comments#action_12343196 ] 
            
Manik Surtani commented on JBCACHE-756:
---------------------------------------

This may just be a problem with jboss-serialization.jar and nothing to do with JBoss Cache at all.  Clebert's investigating the potential problem with jboss-serialization.

FYI, JBoss Cache 1.4.0.GA and 1.4.0.SP1 both ship with jboss-serialization-1.0.1.GA.  The potential upside is that if it is a bug in jboss-serialization, fixing the issue will just be upgrading the one jar, and it should be backward-compatible with JBoss Cache 1.4.0.XX.



> Marshaller breaks with Strings of length greater than 32767
> -----------------------------------------------------------
>
>                 Key: JBCACHE-756
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-756
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0, 1.4.0.SP1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> See unit tests added.  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:45:35 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 12:45:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14013080.1158079535628.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Owen Taylor updated JBCACHE-766:
--------------------------------

    Attachment: jbosscache-avoid-return-20060912.patch

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:47:36 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 12:47:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24954112.1158079656489.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343197 ] 
            
Owen Taylor commented on JBCACHE-766:
-------------------------------------

> But that return value isn't needed for replication. So, this patch just nulls out the return value 
> from the two affected methods. 

That's sort of unclear, actually. To clarify: it nulls out the return values when returning them from
_replicate. The actual underlying methods are unmodified.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:49:34 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 12:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
Message-ID: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>

StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
------------------------------------------------------------------------------------------------------------------------

                 Key: JBSER-89
                 URL: http://jira.jboss.com/jira/browse/JBSER-89
             Project: JBoss Serialization
          Issue Type: Bug
    Affects Versions: 1.0.2 GA, 1.0.1 GA
            Reporter: Manik Surtani
         Assigned To: Clebert Suconic


See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:23:36 2006
From: jira-events at jboss.com (Richard Brooks (JIRA))
Date: Tue, 12 Sep 2006 13:23:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-262) Add another
 addFromResourceBundle method to class FacesMessages
Message-ID: <29443818.1158081816808.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-262?page=comments#action_12343198 ] 
            
Richard Brooks commented on JBSEAM-262:
---------------------------------------

(already posted on forum see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90463)

Looking at the diff it appears that the id parameter has been added to the method signatures but isn't passed through unless you use the method with all the parameters (severity, default, etc)

(diff http://fisheye.jboss.org/viewrep/JBoss/jboss-seam/src/main/org/jboss/seam/core/FacesMessages.java?r1=1.17&r2=1.18)

I haven't actually run the code as I only came across it trying to do the same thing in 1.0.1 GA so I could be mistaken

> Add another addFromResourceBundle method to class FacesMessages
> ---------------------------------------------------------------
>
>                 Key: JBSEAM-262
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-262
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>            Reporter: Bruce Raggett
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Is it possible to add another addFromResourceBundle method to class FacesMessages which would accept a JSF component id parameter? This enhancement would make it easy for a session bean to display a localized message from the resource bundle against a specific JSF input field.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:27:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 13:27:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-315) Break locks for
	state transfer
Message-ID: <12363765.1158082054842.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]

Brian Stansberry updated JBCACHE-315:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76038

> Break locks for state transfer
> ------------------------------
>
>                 Key: JBCACHE-315
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-315
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>            Priority: Critical
>             Fix For: 2.1.0
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:27:35 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Tue, 12 Sep 2006 13:27:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3644) ejbqltosql92compiler
 creates LEFT OUTER JOIN when INNER JOIN would be faster
Message-ID: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>

ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
----------------------------------------------------------------------------

                 Key: JBAS-3644
                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.0.3 SP1
         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
            Reporter: anajavi
         Assigned To: Alexey Loubyansky


Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 

Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).

I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.

I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).

I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.

Example:
Original EJBQL:

SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2

Generated SQL:

SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o 
LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'


10x faster SQL:

SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o 
INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'

Thank you.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:33:34 2006
From: jira-events at jboss.com (Edward Lu (JIRA))
Date: Tue, 12 Sep 2006 13:33:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3643) null message blob
 is created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
In-Reply-To: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24518950.1158082414066.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3643?page=all ]

Edward Lu reopened JBAS-3643:
-----------------------------

             
Please indicate the duplicate bug number.  As of 4.0.4 GA, the issue is not fixed.  

In OracleThinPersistenceManager.add, after the LOCK_EMPTY_BLOB (select messageblob for update), it closes statement and result set, and then does a UPDATE_MESSAGE (update messageblob) instead of writing message content into blob locator.  The code works for message < 4k but not message > 4k.



> null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Windows XP, Oracle 9.2.0.5
>            Reporter: Edward Lu
>            Priority: Critical
>
> A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):
> I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.
> Your help is highly appreciated.
> ****************************************************************************************
> SQL> select count(*) from jms_messages where messageblob is null;
>   COUNT(*)
> ----------
>          3
> *******************************************************************************************
> 2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
> org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
> (java.lang.NullPointerException)^M
>         at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
>         at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
>         at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
>         at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M
> ......
> ......
> Caused by: java.lang.NullPointerException^M
>         at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
>         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
>         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
>         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
>         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M
> *******************************************************************************************************************

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:54:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 13:54:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10553249.1158083684027.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Brian Stansberry updated JBCACHE-766:
-------------------------------------

    Fix Version/s:     (was: 1.4.0.SP2)

Interesting.  I think JBCACHE-752 is the right solution for the marshalling issue (doing it well gives the opportunity to add efficiencies in addition to fixing classloading).  But, you're right -- if we're returning a value from a replicated put, that's not necessary and beyond potential classloading problems it's wasted effort.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:54:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 13:54:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23485887.1158083684215.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343203 ] 
            
Brian Stansberry commented on JBCACHE-766:
------------------------------------------

I removed the Fix Version, as that decision i's neither of our's; it's Manik Surtani's.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:00:44 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 14:00:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3995603.1158084044085.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343204 ] 
            
Owen Taylor commented on JBCACHE-766:
-------------------------------------

Sorry about the fix version ... I thought that was the affected version field. I (happily)
don't have the sort of familiarity with the JIRA UI that I have with bugzilla.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:12:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 12 Sep 2006 14:12:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33439732.1158084763863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Roy Russo resolved JBPORTAL-1029.
---------------------------------

    Resolution: Done

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final, 2.6.Alpha1
>            Reporter: Morten Hauch
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:24:32 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 14:24:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-767) Fail more silently
 when setting node versions
Message-ID: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fail more silently when setting node versions
---------------------------------------------

                 Key: JBCACHE-767
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
             Project: JBoss Cache
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani
            Priority: Minor
         Attachments: jbosscache-fail-more-silently-20060912.patch

Hibernate's OptimisticTreeCache.writeUpdate does:

                        Option option = new Option();
                        option.setFailSilently( true );
                        option.setDataVersion( NonLockingDataVersion.INSTANCE );
                        cache.remove( new Fqn( regionFqn, key ), "ITEM", option );

Which you would expect would remove the item if it exists, while setting the data version,
and silently do nothing otherwise. But it ends up, logging at level INFO:

12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
java.lang.NullPointerException
        at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
        at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
        at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
        at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
        at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
        at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)

There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
problem.

What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
NullPointerException.




-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:24:33 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 14:24:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-767) Fail more silently
 when setting node versions
In-Reply-To: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4388295.1158085473071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]

Owen Taylor updated JBCACHE-767:
--------------------------------

    Attachment: jbosscache-fail-more-silently-20060912.patch

> Fail more silently when setting node versions
> ---------------------------------------------
>
>                 Key: JBCACHE-767
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-fail-more-silently-20060912.patch
>
>
> Hibernate's OptimisticTreeCache.writeUpdate does:
>                         Option option = new Option();
>                         option.setFailSilently( true );
>                         option.setDataVersion( NonLockingDataVersion.INSTANCE );
>                         cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
> Which you would expect would remove the item if it exists, while setting the data version,
> and silently do nothing otherwise. But it ends up, logging at level INFO:
> 12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
> java.lang.NullPointerException
>         at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
>         at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
>         at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
>         at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
> There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
> too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
> problem.
> What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
> setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:08:31 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Tue, 12 Sep 2006 15:08:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26919603.1158088111632.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343208 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

Iv'e also made a second version of the icon using the JBOSS corporate red.


http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm


16 x 16
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside_2.gif

32 x 32
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside_v2.gif

They can be seen in action here:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_jbosside_page_v2.gif

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:26:35 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 15:26:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-5) Integrate OpenDS in
 HEAD testsuite
Message-ID: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate OpenDS in HEAD testsuite
----------------------------------

                 Key: SECURITY-5
                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule

Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.

My prelim testing details:
====================================================================
C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
[12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
 Directory Server 0.1-build007 starting up."
[12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
database backend containing 1 entries has started."
[12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
msg="Access control has been disabled."
[12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
rectory Server has started successfully."
[12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
rectory Server has sent an alert notification generated by class org.opends.serv
er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
ert ID 458887):  The Directory Server has started successfully.."
================================================================================


=============================================================================
C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
-D "cn=Directory Manager" -w password -a -f a.ldif

Processing ADD request for dc=jboss,dc=org.

ADD operation successful for DN dc=jboss,dc=org.

Processing ADD request for ou=People,dc=jboss,dc=org.

ADD operation successful for DN ou=People,dc=jboss,dc=org.

Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.

ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.

Processing ADD request for ou=Roles,dc=jboss,dc=org.

ADD operation successful for DN ou=Roles,dc=jboss,dc=org.

Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.

ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.

Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.

ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
===============================================================================

==============================================================================
C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
 -b "dc=jboss,dc=org" -s sub "objectclass=*"

dn: dc=jboss,dc=org

objectClass: top

objectClass: dcObject

objectClass: organization

o: JBoss

dc: jboss

dn: ou=People,dc=jboss,dc=org

objectClass: top

objectClass: organizationalUnit

ou: People

dn: uid=jduke,ou=People,dc=jboss,dc=org

objectClass: top
objectClass: person
objectClass: uidObject
userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
cn: Java Duke
sn: Duke
uid: jduke
=====================================================================================

The application policy:
<application-policy name = "jmx-console">
        <authentication>
            <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
                          flag="required">
                <module-option name="java.naming.factory.initial"> 
                    com.sun.jndi.ldap.LdapCtxFactory
                    </module-option>
                <module-option name="java.naming.provider.url">
                    ldap://localhost:389/
                </module-option>
                <module-option name="java.naming.security.authentication">
                    simple
                </module-option>
                <module-option name="principalDNPrefix">uid=</module-option>                    
                <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
                <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
                <module-option name="uidAttributeID">member</module-option>
                <module-option name="matchOnUserDN">true</module-option>
                <module-option name="roleAttributeID">cn</module-option>
                <module-option name="roleAttributeIsDN">false</module-option>
                <module-option name="searchTimeLimit">5000</module-option>
                <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
            </login-module>
        </authentication>
    </application-policy>


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:26:36 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 15:26:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (SECURITY-4) Evaluate OpenDS
 (Sun's OSS all-java Directory Server)
In-Reply-To: <3697073.1158076117046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14329396.1158089196086.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-4?page=all ]

Anil Saldhana reassigned SECURITY-4:
------------------------------------

    Assignee: Anil Saldhana  (was: Scott M Stark)

> Evaluate OpenDS (Sun's OSS all-java Directory Server)
> -----------------------------------------------------
>
>                 Key: SECURITY-4
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-4
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> https://opends.dev.java.net/public/docs/OpenDS-FAQ.html
> - Requires JDK5. 
> - Java only.
> - Ldif import/export supported.
> Good candidate for HEAD testsuite integration.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:26:36 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 15:26:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-4) Evaluate OpenDS
 (Sun's OSS all-java Directory Server)
In-Reply-To: <3697073.1158076117046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32882535.1158089196236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-4?page=all ]

Anil Saldhana closed SECURITY-4.
--------------------------------

    Resolution: Done

Preliminary testing has been successful as outlined in SECURITY-5

Will attempt integration in HEAD testsuite.

> Evaluate OpenDS (Sun's OSS all-java Directory Server)
> -----------------------------------------------------
>
>                 Key: SECURITY-4
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-4
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> https://opends.dev.java.net/public/docs/OpenDS-FAQ.html
> - Requires JDK5. 
> - Java only.
> - Ldif import/export supported.
> Good candidate for HEAD testsuite integration.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:48:34 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 15:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3645) LdapExtLoginModule
 still has connection leak
Message-ID: <20371850.1158090514725.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule still has connection leak
--------------------------------------------

                 Key: JBAS-3645
                 URL: http://jira.jboss.com/jira/browse/JBAS-3645
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:56:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 15:56:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3646) LdapExtLoginModule
 still has connection leak
Message-ID: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule still has connection leak
--------------------------------------------

                 Key: JBAS-3646
                 URL: http://jira.jboss.com/jira/browse/JBAS-3646
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA


The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:56:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 15:56:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (SECURITY-6) LdapExtLoginModule
 still has connection leak
In-Reply-To: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17624522.1158090999813.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-6?page=all ]

Scott M Stark moved JBAS-3646 to SECURITY-6:
--------------------------------------------

    Affects Version/s:     (was: JBossAS-4.0.4.GA)
              Project: JBoss Security  (was: JBoss Application Server)
                  Key: SECURITY-6  (was: JBAS-3646)
          Component/s: JBossSX
                           (was: Security)
        Fix Version/s:     (was: JBossAS-5.0.0.Beta)
                           (was: JBossAS-4.0.5.GA)

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: SECURITY-6
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-6
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 16:31:36 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Tue, 12 Sep 2006 16:31:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-749) Make
 BdbjeCacheLoader use the
 standard format for persistent state transfer
In-Reply-To: <17190799.1156632131571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23942570.1158093096927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-749?page=all ]

Vladimir Blagojevic resolved JBCACHE-749.
-----------------------------------------

    Resolution: Done

Resolved by moving storeState/loadState methods up to AbstractCacheLoader

> Make BdbjeCacheLoader use the standard format for persistent state transfer
> ---------------------------------------------------------------------------
>
>                 Key: JBCACHE-749
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-749
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>            Reporter: Brian Stansberry
>
> The state should be a sequence of NodeData objects; see FileCacheLoader or JDBCCacheLoader.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 16:49:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 16:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-6) LdapExtLoginModule
 still has connection leak
In-Reply-To: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24472954.1158094174956.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-6?page=all ]

Anil Saldhana updated SECURITY-6:
---------------------------------

    Affects Version/s: 2.0
                       1.x
        Fix Version/s: 1.x
                       2.0

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: SECURITY-6
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-6
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 1.x, 2.0
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.x, 2.0
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:34:35 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 17:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3645) LdapExtLoginModule
 still has connection leak
In-Reply-To: <20371850.1158090514725.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1700732.1158096875411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3645?page=all ]

Scott M Stark closed JBAS-3645.
-------------------------------

    Resolution: Done

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3645
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3645
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:34:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 12 Sep 2006 17:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9996235.1158096875588.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic reassigned JBMESSAGING-541:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Tom  Elrod)

> Crash Test failure on Durable Subscriber
> ----------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> DurableSubscriberCrashTest1 and 2 are failing.
> The routine that verifies if a connection is broken is only called upon communication exceptions. 
> If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:36:32 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 17:36:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3647) Backport
 SingleRetryInterceptor to 3.2
Message-ID: <4654533.1158096992808.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport SingleRetryInterceptor to 3.2
--------------------------------------

                 Key: JBAS-3647
                 URL: http://jira.jboss.com/jira/browse/JBAS-3647
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, EJB2
    Affects Versions: JBossAS-3.2.8.SP1
            Reporter: Scott M Stark
         Assigned To: Brian Stansberry


A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1:

2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException:
org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918)

We should backport this.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:38:37 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 17:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3648) Need a clustered ejb
 compatibility test
Message-ID: <17070980.1158097117897.JavaMail.jira@cloud.prod.atl2.jboss.com>

Need a clustered ejb compatibility test
---------------------------------------

                 Key: JBAS-3648
                 URL: http://jira.jboss.com/jira/browse/JBAS-3648
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-3.2.8.SP1
            Reporter: Scott M Stark
         Assigned To: Brian Stansberry


We need a test of a 3.2.x client talking to a 4.0.x clustered ejb to validate interop.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 18:04:31 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Tue, 12 Sep 2006 18:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1033) PortletContainer
 added logging causes class loading issues.
Message-ID: <4364937.1158098671693.JavaMail.jira@cloud.prod.atl2.jboss.com>

PortletContainer added logging causes class loading issues.
-----------------------------------------------------------

                 Key: JBPORTAL-1033
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1033
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4 Final, 2.2.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1


In PortletContainer constructor:
this.portletLog = Logger.getLogger(metaData.getClassName());
causes Log4J to be loaded in several different class loaders causing CCEs.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 18:10:31 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 18:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-6) LdapExtLoginModule
 still has connection leak
In-Reply-To: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22404453.1158099031127.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-6?page=all ]

Scott M Stark closed SECURITY-6.
--------------------------------

    Resolution: Done

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: SECURITY-6
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-6
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 1.x, 2.0
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.x, 2.0
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:36:44 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32382560.1158107804279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Ben Wang updated JBCACHE-765:
-----------------------------

    Fix Version/s: 2.0.0

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:36:44 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-765) implementation
 of equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19845506.1158107804439.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=comments#action_12343226 ] 
            
Ben Wang commented on JBCACHE-765:
----------------------------------

I can take a look early next week. Or do you have a patch ready that you can attach?

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:38:43 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12260377.1158107923972.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Ben Wang updated JBCACHE-763:
-----------------------------

    Fix Version/s: 2.0.0

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:40:43 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:40:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26333263.1158108043891.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Ben Wang updated JBCACHE-760:
-----------------------------

    Fix Version/s: 2.0.0
                   1.4.0.SP2

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0, 1.4.0.SP2
>
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:56:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 12 Sep 2006 20:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21773216.1158109003844.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Description: 
IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:


	      conn1 = cf.createConnection();
	      conn1.setClientID("test1");
	      conn1.start();

	      conn2 = cf.createConnection();
	      conn2.setClientID("test2");
	      conn2.start();

	      conn1.close();


  was:
DurableSubscriberCrashTest1 and 2 are failing.
The routine that verifies if a connection is broken is only called upon communication exceptions. 

If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

        Summary: If the first opened connections is closed, Remoting Lease doesn't work any more  (was: Crash Test failure on Durable Subscriber)

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 12 20:56:44 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 12 Sep 2006 20:56:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17410853.1158109004019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Comment: was deleted

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 12 21:10:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 21:10:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3639) Lookup fails during
	failover
In-Reply-To: <8989834.1157983952060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <264847.1158109843912.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3639?page=all ]

Brian Stansberry updated JBAS-3639:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90404  (was: http://jboss.com/index.html?module=bb&op=viewtopic&p=3949184#3949184)

For whatever reason our forum wouldn't let me reply to the forum thread you opened a while back, so I just started a new one at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90404 and replied there.

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBAS-3639
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3639
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.6 Final, JBossAS-4.0.4RC1
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534)
> This happened on our test cluster.
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.
> I tested with jboss 4.0.4 and the problem still exists

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 22:00:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 22:00:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3649) Startup switches
 should set the new JGroups system properties
Message-ID: <13306029.1158112843780.JavaMail.jira@cloud.prod.atl2.jboss.com>

Startup switches should set the new JGroups system properties
-------------------------------------------------------------

                 Key: JBAS-3649
                 URL: http://jira.jboss.com/jira/browse/JBAS-3649
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


JGroups has created a more formalized system for the names of the system properties it uses (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps).  We need to ensure that when the JBoss AS command-line switches are used, the new system properties get set:

-b jgroups.bind_addr
-u  jgroups.udp.mcast_addr

The old properties will be set as well to ensure legacy config files still work.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 00:00:31 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 00:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3650) LdapExtLoginModule
 still has connection leak
Message-ID: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule still has connection leak
--------------------------------------------

                 Key: JBAS-3650
                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 00:17:43 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 00:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3120192.1158121063856.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3650?page=comments#action_12343229 ] 
            
Scott M Stark commented on JBAS-3650:
-------------------------------------

[sstark at sstark Patches]$ svn copy -m "Patch for LdapExtLoginModule still has connection leak" https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_3_SP1 https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_3_SP1_JBAS-3650

Committed revision 56790.


> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 02:49:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 13 Sep 2006 02:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3649) Startup switches
 should set the new JGroups system properties
In-Reply-To: <13306029.1158112843780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21070985.1158130183806.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3649?page=comments#action_12343230 ] 
            
Dimitris Andreadis commented on JBAS-3649:
------------------------------------------

Nice. You should rename your Wiki Page though:

SystemProps --> JGroupSystemProps

:-)

> Startup switches should set the new JGroups system properties
> -------------------------------------------------------------
>
>                 Key: JBAS-3649
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3649
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.Beta
>
>
> JGroups has created a more formalized system for the names of the system properties it uses (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps).  We need to ensure that when the JBoss AS command-line switches are used, the new system properties get set:
> -b jgroups.bind_addr
> -u  jgroups.udp.mcast_addr
> The old properties will be set as well to ensure legacy config files still work.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 03:29:44 2006
From: jira-events at jboss.com (Richard C. L. Li (JIRA))
Date: Wed, 13 Sep 2006 03:29:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3385) cmp2.x jdbc2 pm
 Failed to Deploy
 2 Identical EARs with Different Datasource Configuration
In-Reply-To: <703339.1152676762037.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22435302.1158132584973.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3385?page=all ]

Richard C. L. Li updated JBAS-3385:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> cmp2.x jdbc2 pm Failed to Deploy 2 Identical EARs with Different Datasource Configuration
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-3385
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3385
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Richard C. L. Li
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: EntityTable.diff
>
>
> Deploying 2 Identical EARs with different datasource configuration will generate the following exception:
> 2006-07-11 12:54:36,458 INFO  [org.jboss.ejb.plugins.cmp.jdbc2.schema.PartitionedTableCache] Registration is not done -> stop
> 2006-07-11 12:54:36,458 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:module=retailsales.jar,uid=12606869,service=EjbModule
> org.jboss.deployment.DeploymentException: Failed to register table cache for memo; - nested throwable: (javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:216)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.Schema.createEntityTable(Schema.java:93)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.bridge.JDBCEntityBridge2.<init>(JDBCEntityBridge2.java:80)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.initStoreManager(JDBCStoreManager2.java:437)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.start(JDBCStoreManager2.java:175)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
> 	at org.jboss.ejb.EntityContainer.startPmAndInterceptors(EntityContainer.java:1063)
> 	at org.jboss.ejb.EjbModule.startService(EjbModule.java:422)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy16.start(Unknown Source)
> 	at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
> 	at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy17.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> 	at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy8.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
> Caused by: javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:761)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:225)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:211)
> 	... 67 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 03:47:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 13 Sep 2006 03:47:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3385) cmp2.x jdbc2 pm
 Failed to Deploy
 2 Identical EARs with Different Datasource Configuration
In-Reply-To: <703339.1152676762037.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32710194.1158133663924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3385?page=all ]

Dimitris Andreadis updated JBAS-3385:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

Please, let the developer define the fix version.

> cmp2.x jdbc2 pm Failed to Deploy 2 Identical EARs with Different Datasource Configuration
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-3385
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3385
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Richard C. L. Li
>         Assigned To: Alexey Loubyansky
>         Attachments: EntityTable.diff
>
>
> Deploying 2 Identical EARs with different datasource configuration will generate the following exception:
> 2006-07-11 12:54:36,458 INFO  [org.jboss.ejb.plugins.cmp.jdbc2.schema.PartitionedTableCache] Registration is not done -> stop
> 2006-07-11 12:54:36,458 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:module=retailsales.jar,uid=12606869,service=EjbModule
> org.jboss.deployment.DeploymentException: Failed to register table cache for memo; - nested throwable: (javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:216)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.Schema.createEntityTable(Schema.java:93)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.bridge.JDBCEntityBridge2.<init>(JDBCEntityBridge2.java:80)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.initStoreManager(JDBCStoreManager2.java:437)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.start(JDBCStoreManager2.java:175)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
> 	at org.jboss.ejb.EntityContainer.startPmAndInterceptors(EntityContainer.java:1063)
> 	at org.jboss.ejb.EjbModule.startService(EjbModule.java:422)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy16.start(Unknown Source)
> 	at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
> 	at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy17.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> 	at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy8.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
> Caused by: javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:761)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:225)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:211)
> 	... 67 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 04:25:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 13 Sep 2006 04:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
Message-ID: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>

Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
---------------------------------------------------------

                 Key: JBAS-3651
                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
             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 hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 04:45:44 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Wed, 13 Sep 2006 04:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30270443.1158137144041.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Nitzan Niv updated JBCACHE-765:
-------------------------------

    Attachment: CachedMapImpl.java
                CachedListAbstract.java

Attached are versions with fixed equals().
The fixed List implementation also contains a hashCode caculation as defined in the List Javadoc.

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: CachedListAbstract.java, CachedMapImpl.java
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 04:51:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Wed, 13 Sep 2006 04:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5281842.1158137503919.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Nitzan Niv updated JBCACHE-765:
-------------------------------

    Attachment: CachedMapImpl.java
                CachedListAbstract.java

I'm attaching updated versions of the files that also handle correctly comparison to null.

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: CachedListAbstract.java, CachedListAbstract.java, CachedMapImpl.java, CachedMapImpl.java
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 05:55:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 05:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-315) Break locks for
	state transfer
Message-ID: <19059415.1158141343902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]

Manik Surtani updated JBCACHE-315:
----------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.1.0)
          Affects: [Documentation (Ref Guide, User Guide, etc.)]
       Complexity: High

Targetting this for 2.0.0 rather than 2.1.0

> Break locks for state transfer
> ------------------------------
>
>                 Key: JBCACHE-315
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-315
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 05:55:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 05:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-326) Create the concept
 of a
 "priority queue" to speed execution of certain remote method invocations
Message-ID: <29039493.1158141344052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-326?page=all ]

Manik Surtani updated JBCACHE-326:
----------------------------------

    Complexity: Medium
      Assignee: Vladimir Blagojevic  (was: Bela Ban)

Are we still doing this?  This is the concept of a separate 'processor' thread for state events.

> Create the concept of a "priority queue" to speed execution of certain remote method invocations
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-326
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-326
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0
>
>
> Change the handling of requests in JBossCache (another  interceptor on top of ReplicationInterceptor): 
> - Create 2 queues (of MethodCall objects), one thread for each queue 
> - The regular MethodCalls like put(), remove() etc go into the  default queue (A), where they are processed according to order (FIFO) 
> - The special calls like block(), _getState(), commit() or acks  for PREPARE/COMMIT calls go into the other (priority) queue (B),  these calls *CAN* be received out of sequence 
> - This way, an _getState() would always be processed and  would be able to (1) stop the processing of queue A and (2) force- release any locks held 
>   by on the tree.
> _ This way commit() calls can promptly release locks, without having to wait behind other prepare 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

        


From jira-events at jboss.com  Wed Sep 13 06:23:43 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 13 Sep 2006 06:23:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1034) prototype ldap
	in portal
Message-ID: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>

prototype ldap in portal
------------------------

                 Key: JBPORTAL-1034
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz


prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:25:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-328) Move attributes and
 getters/setters to interceptors
Message-ID: <19987850.1158143143939.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ]

Manik Surtani closed JBCACHE-328.
---------------------------------

    Resolution: Won't Fix

A different approach is used instead.  Cache-wide configuration is encapsulated in a Configuration object, which is injected into each of the interceptors.  

This way the config can be managed independent of the interceptors.

> Move attributes and getters/setters to interceptors
> ---------------------------------------------------
>
>                 Key: JBCACHE-328
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-328
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> Example: currently IsolationLevel is an attribute of TreeCache. Goal is to make it an attribute of PessimisticLockingInterceptor.
> Advantage:no unneeded methods in TreeCache, cluttering up the TreeCache class
> #1 Implicit Configuration (conceptual)
> --------------------
> <TreeCache>
>    <Replication>
>        <config> ... </config>
>        <mode>ASYNC</mode>
>     </Replication>
>     <IsolationLevel>
>          REPEATABLE-READ
>      </IsolationLevel>
> </TreeCache>
> This configures the interceptor chain
> #2 Explicit configuration
> ------------------------------------
> <TreeCache>
>    <Interceptor name="PessimisticLockingInterceptor"
>                      class="xxxx"
>                       level="REPEATABLE-READ" />
>     <Interceptor>...</Interceptor>
> </TreeCache>
> The chain is defined explicitly, attributes are defines per interceptor
> #3 JMX
> If JMx is used, JBossCache is registered with the MBeanServer, and all interceptors are registered under JBossCache, e.g.
> type=cache;name=JBossCache1
> type=cache;name=JBossCache1;interceptor_name=PessimisticLockingInterceptor
> type=cache;name=JBossCache1;interceptor_name=CacheLoaderInterceptor
> type=cache;name=JBossCache1;interceptor_name=ReplicationInterceptor
> #4 Programmatic access
> Can be done through JMX, but is not nice
> cache.getIsolationLevel() --> ((PessimisticLockingInterceptor)cache.getInterceptor("PessimisticLockingInterceptor")).getIsolationLevel()

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-692) UPdate unit tests
 to use new interfaces
In-Reply-To: <16805200.1152789131289.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17698756.1158143144020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-692?page=all ]

Manik Surtani closed JBCACHE-692.
---------------------------------

    Resolution: Done

> UPdate unit tests to use new interfaces
> ---------------------------------------
>
>                 Key: JBCACHE-692
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-692
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-768) Finalise JMX
 interface for Cache
Message-ID: <20732681.1158143144092.JavaMail.jira@cloud.prod.atl2.jboss.com>

Finalise JMX interface for Cache
--------------------------------

                 Key: JBCACHE-768
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-768
             Project: JBoss Cache
          Issue Type: Sub-task
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-768) Finalise JMX
 interface for Cache
In-Reply-To: <20732681.1158143144092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14804028.1158143144169.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-768?page=all ]

Manik Surtani updated JBCACHE-768:
----------------------------------

               Complexity: Medium
                  Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial, Compatibility/Configuration]
    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971235#3971235

> Finalise JMX interface for Cache
> --------------------------------
>
>                 Key: JBCACHE-768
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-768
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-768) Finalise JMX
 interface for Cache
In-Reply-To: <20732681.1158143144092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13303733.1158143144239.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-768?page=all ]

Manik Surtani updated JBCACHE-768:
----------------------------------

    Fix Version/s: 2.0.0

> Finalise JMX interface for Cache
> --------------------------------
>
>                 Key: JBCACHE-768
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-768
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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

        


From jira-events at jboss.com  Wed Sep 13 06:37:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-767) Fail more silently
 when setting node versions
In-Reply-To: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23881614.1158143863828.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]

Manik Surtani updated JBCACHE-767:
----------------------------------

    Fix Version/s: 2.0.0
                   1.4.0.SP2

Thanks for this patch

> Fail more silently when setting node versions
> ---------------------------------------------
>
>                 Key: JBCACHE-767
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>         Attachments: jbosscache-fail-more-silently-20060912.patch
>
>
> Hibernate's OptimisticTreeCache.writeUpdate does:
>                         Option option = new Option();
>                         option.setFailSilently( true );
>                         option.setDataVersion( NonLockingDataVersion.INSTANCE );
>                         cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
> Which you would expect would remove the item if it exists, while setting the data version,
> and silently do nothing otherwise. But it ends up, logging at level INFO:
> 12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
> java.lang.NullPointerException
>         at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
>         at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
>         at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
>         at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
> There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
> too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
> problem.
> What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
> setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:39:43 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 13 Sep 2006 06:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23972499.1158143983837.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=comments#action_12343240 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1034:
-----------------------------------------------

apacheDS is badly documented. This makes life much easier for embedding it:
http://docs.safehaus.org/display/APACHEDS/Embedding+ApacheDS
http://docs.safehaus.org/pages/viewpage.action?pageId=4982
and especially this:
https://svn.safehaus.org/repos/sandbox/apachecon/ldap/src/main/java/apachecon/ldap/LdapExposingApplication.java



> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>
> prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:39:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-767) Fail more silently
 when setting node versions
In-Reply-To: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27514075.1158143983965.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]

Manik Surtani closed JBCACHE-767.
---------------------------------

    Resolution: Done

> Fail more silently when setting node versions
> ---------------------------------------------
>
>                 Key: JBCACHE-767
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2, 2.0.0
>
>         Attachments: jbosscache-fail-more-silently-20060912.patch
>
>
> Hibernate's OptimisticTreeCache.writeUpdate does:
>                         Option option = new Option();
>                         option.setFailSilently( true );
>                         option.setDataVersion( NonLockingDataVersion.INSTANCE );
>                         cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
> Which you would expect would remove the item if it exists, while setting the data version,
> and silently do nothing otherwise. But it ends up, logging at level INFO:
> 12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
> java.lang.NullPointerException
>         at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
>         at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
>         at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
>         at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
> There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
> too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
> problem.
> What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
> setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:49:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <438840.1158144583912.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani updated JBCACHE-766:
----------------------------------

    Fix Version/s: 1.4.0.SP2
                   2.0.0

Hacky, agreed, but effective.  :-)

In fact, I think this (as a concept) should be integrated to JBCACHE-752 (and I will x-reference accordingly) but for the 1.4.0 series, this patch can be introduced without breaking compatibility.

Extending the patch to cover remove(fqn, key) as well.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:49:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:49:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30042871.1158144584022.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani updated JBCACHE-766:
----------------------------------

    Fix Version/s:     (was: 2.0.0)

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:53:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-752) Look into using
 JBC Marshaller implementations for responses as well as requests
In-Reply-To: <13898767.1156863079702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12393485.1158144823788.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12343243 ] 
            
Manik Surtani commented on JBCACHE-752:
---------------------------------------

See JBCACHE-766.

Some methods - put(fqn, key, value) and remove(fqn, key) - return the old value of the attribute.  Thi sreturn value is only used in the "local" version of the method.  The return value is not used in "remote" versions.  

Returning nulls for these (if remote) will simplify classloading and improve marshalling (of return values) performance, and reduce network traffic.

> Look into using JBC Marshaller implementations for responses as well as requests
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-752
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-752
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.0.0
>
>
> In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was added.  At some point JGroups may require that the *same* marshaller instance handle both.  JBC's current marshallers can't do this; need to look into what it would take to do it.
> Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for RPC based state transfer).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:59:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33239127.1158145183832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani closed JBCACHE-766.
---------------------------------

    Resolution: Done

Thanks for the patch

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 07:01:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 07:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-752) Look into using
 JBC Marshaller implementations for responses as well as requests
In-Reply-To: <13898767.1156863079702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23161040.1158145303786.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12343245 ] 
            
Manik Surtani commented on JBCACHE-752:
---------------------------------------

Note that JBCACHE-766 was only applied to the 1.4.0 branch - not the 2.0.0 one

> Look into using JBC Marshaller implementations for responses as well as requests
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-752
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-752
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.0.0
>
>
> In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was added.  At some point JGroups may require that the *same* marshaller instance handle both.  JBC's current marshallers can't do this; need to look into what it would take to do it.
> Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for RPC based state transfer).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 07:17:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 07:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-490) All nodes to only
 have mandatory fields defined
Message-ID: <4039278.1158146263875.JavaMail.jira@cloud.prod.atl2.jboss.com>

All nodes to only have mandatory fields defined
-----------------------------------------------

                 Key: JBRULES-490
                 URL: http://jira.jboss.com/jira/browse/JBRULES-490
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 07:22:24 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 07:22:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-490) All nodes to
 only have mandatory fields defined
In-Reply-To: <4039278.1158146263875.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7362379.1158146544377.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-490?page=comments#action_12343246 ] 
            
Michael Neale commented on JBRULES-490:
---------------------------------------

should be able to make it like nt:undefined so we don't have to migrate if there are new fields added.

> All nodes to only have mandatory fields defined
> -----------------------------------------------
>
>                 Key: JBRULES-490
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-490
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:05:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-314) Integrate handling of
 block()/blockOk() into Multiplexer
Message-ID: <30162259.1158149143820.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate handling of block()/blockOk() into Multiplexer
--------------------------------------------------------

                 Key: JGRP-314
                 URL: http://jira.jboss.com/jira/browse/JGRP-314
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


Currently, blocks are not passed up to the Multiplexer, and the MuxChannel's blockOk() method is a no-op

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:07:44 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12361905.1158149264009.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Tim Fox updated JBMESSAGING-541:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                       (was: 1.0.1.CR5)
                   1.0.1.GA

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.0.1.GA
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Wed Sep 13 08:07:44 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <10783372.1158149264219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Tim Fox updated JBMESSAGING-207:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:10:39 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:10:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-92) Integrate and
 enable multiplex transport
Message-ID: <26967733.1158149439261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-92?page=all ]

Tim Fox updated JBMESSAGING-92:
-------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Integrate and enable multiplex transport
> ----------------------------------------
>
>                 Key: JBMESSAGING-92
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-92
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Replace "Connector per Consumer" solution with a Remoting UIL2-like transport
> The ConsumerInterceptor creates a new Connector instance per each Consumer, and associates maintains a reference to it as transitory metadata, so it can shut it down when the Consumer closes. 
> The Connector is necessary as a callback server for asynchronous notifications. The MessageCallbackHandler instance is registered to it. Maintaining an instance per Consumer is necessary to avoid port conflicts.
> This is a temporary solution until JBoss Remoting gets an UIL2-like transport.
> As long as we maintain a server socket per consumer, it won't be possbile to receive asynchronous notifications over firewalls.
> until multiplex performance is better it should not be the default tranport but should be available nevertheless

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:10:39 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:10:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-455) CVS to SVN
 repository migration
In-Reply-To: <2712491.1154459591320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24870613.1158149439367.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-455?page=all ]

Tim Fox updated JBMESSAGING-455:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> CVS to SVN repository migration
> -------------------------------
>
>                 Key: JBMESSAGING-455
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-455
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:12:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:12:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-199) Fix or mothball
 remotetopic
 so it does not require multiple deliveries per message reference
Message-ID: <1477229.1158149555290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ]

Tim Fox closed JBMESSAGING-199.
-------------------------------

    Resolution: Won't Fix

Remote Topic no longer exists in HEAD with new clustering code

> Fix or mothball remotetopic so it does not require multiple deliveries per message reference
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-199
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>
> Re-implement remote topic to be a router with multiple channels - one per peer.
> This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:12:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:12:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-228) Re-enable
 DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()
Message-ID: <25636677.1158149555504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ]

Tim Fox closed JBMESSAGING-228.
-------------------------------

      Assignee: Tim Fox  (was: Ovidiu Feodorov)
    Resolution: Won't Fix

Old distributed tests are no longer relevant since we no longer use the old clustering code base

> Re-enable DistributedTopicTest testDistributedTopic_2() and  testDistributedTopic_4()
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-228
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and  testDistributedTopic_4(()
> because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run.
> Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:14:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-267) Re-enable
	distributed tests
Message-ID: <29102012.1158149673559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ]

Tim Fox closed JBMESSAGING-267.
-------------------------------

      Assignee: Tim Fox
    Resolution: Won't Fix

These tests are no longer relevant since they test the old clustering code base which is no longer used

> Re-enable distributed tests
> ---------------------------
>
>                 Key: JBMESSAGING-267
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0.
> These tests should be re-enabled and adjusted as necessary for the 1.2 release.
> All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:14:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-404) Remove
 Channel::deliver(Receiver r) method
Message-ID: <14667824.1158149673686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ]

Tim Fox closed JBMESSAGING-404.
-------------------------------

    Resolution: Done

With the new push style of delivery, this method no longer exists

> Remove Channel::deliver(Receiver r) method
> ------------------------------------------
>
>                 Key: JBMESSAGING-404
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This method is used to effectively do a synchronous receive() on a channel.
> The functionality could be more simply implemented by doing adding a MessageReference receive() method.
> This would also help in a clustered environment since we would have one less network RPC.
> Most of the complexity here is in updating tests.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:16:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:16:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <19089706.1158149795983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Tim Fox updated JBMESSAGING-431:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ron Sigal
>             Fix For: 1.2.0.Beta1
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:16:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:16:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-467) Sort out JBoss
 AS dependencies
In-Reply-To: <9629814.1154476211339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9709195.1158149796112.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-467?page=all ]

Tim Fox updated JBMESSAGING-467:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Sort out JBoss AS dependencies
> ------------------------------
>
>                 Key: JBMESSAGING-467
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-467
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>
> Currently we've imported JBossAS in the lib area of our project to keep the project compiling. This is hardly an acceptable solution. The proper solution involves:
> 1) Deciding what JBossAS depenencies we need and getting rid of artificially introduced dependencies
> 2) Work with AS team to identifiy the AS interfaces that need to be isolated and exposed in the repository.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:16:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:16:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <9702429.1158149796264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Tim Fox closed JBMESSAGING-361.
-------------------------------

    Resolution: Done

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:18:40 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:18:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-468) Re-activate
 the perf framework under the new build system
In-Reply-To: <20185700.1154476571322.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18560378.1158149920233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-468?page=all ]

Tim Fox updated JBMESSAGING-468:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Re-activate the perf framework under the new build system
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-468
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-468
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>
> Make sure perf framework works correctly
> Find the right location for       
> <path location="../src/resources/jcommon-1.0.0-rc1.jar"/>
>  <path location="../src/resources/jfreechart-1.0.0-rc1.jar"/>
> Also, restore    <!-- <ant dir="./perf" antfile="build.xml" inheritAll="false" target="clean"/> --> in build-messaging.xml and understand why it tries to delete svn/thirdparty/libraries.ent

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:18:40 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:18:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-192) Refactor
 Replicator so it
 won't be forced to provide noop implementation for Distributor's methods.
Message-ID: <32826551.1158149920385.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ]

Tim Fox closed JBMESSAGING-192.
-------------------------------

    Resolution: Won't Fix
      Assignee: Tim Fox  (was: Ovidiu Feodorov)

Replicator no longer exists in new clustering code base

> Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-192
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR2 (clustered)
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for
> Set handle(DeliveryObserver observer, Routable routable, Transaction transaction)
> However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport  implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor.
> Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:20:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:20:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-200) Complete XA
 transaction recovery
Message-ID: <1816773.1158150034207.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ]

Tim Fox closed JBMESSAGING-200.
-------------------------------

    Resolution: Duplicate Issue

Duplicate of 407

> Complete XA transaction recovery
> --------------------------------
>
>                 Key: JBMESSAGING-200
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Complete XA transaction recovery.
> Most of the work is already in place for this.
> The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery.
> The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager.
> We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:22:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:22:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-332) Consider how
 best to factor paging logic out of channel state
Message-ID: <22468492.1158150154230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ]

Tim Fox closed JBMESSAGING-332.
-------------------------------

    Resolution: Done

Now abstracted out into PagingChannel

> Consider how best to factor paging logic out of channel state
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-332
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete 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

        


From jira-events at jboss.com  Wed Sep 13 08:24:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:24:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-315) Create check list of
	manual tests
Message-ID: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create check list of manual tests
---------------------------------

                 Key: JGRP-315
                 URL: http://jira.jboss.com/jira/browse/JGRP-315
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
- JGroups/doc/tests/GmsTests.txt
- Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:24:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:24:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-310) Investigate
 whether rw lock on ServerConnectionEndpoint is necessary
Message-ID: <13343952.1158150273601.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ]

Tim Fox closed JBMESSAGING-310.
-------------------------------

    Resolution: Done

It's been removed

> Investigate whether rw lock on ServerConnectionEndpoint is necessary
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-310
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:26:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-422) Move channel
 mapper logic into Queue, Topic, Subscription classes
Message-ID: <28676861.1158150393292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ]

Tim Fox closed JBMESSAGING-422.
-------------------------------

    Resolution: Done

These classes no longer exist

> Move channel mapper logic into Queue, Topic, Subscription classes
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-422
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes.
> It's currently a bit of a mess.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:26:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-435) PointToPoint
 delivery with multiple consumers and selectors is broken
In-Reply-To: <23154601.1152954191989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1325853.1158150393432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-435?page=all ]

Tim Fox closed JBMESSAGING-435.
-------------------------------

    Resolution: Done

> PointToPoint delivery with multiple consumers and selectors is broken
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-435
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery.
> If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer.
> Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:28:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:28:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-414) Simplify
	delivery hierarchy
Message-ID: <11740785.1158150512362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox closed JBMESSAGING-414.
-------------------------------

    Resolution: Done

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:28:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:28:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-425) Naming of Pipe
 and Distributed Pipe
Message-ID: <596150.1158150512498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox closed JBMESSAGING-425.
-------------------------------

      Assignee: Tim Fox
    Resolution: Won't Fix

These classes no longer exist

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:30:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:30:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <20635233.1158150633982.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox closed JBMESSAGING-197.
-------------------------------

    Resolution: Done
      Assignee: Tim Fox  (was: Ovidiu Feodorov)

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:30:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <24630983.1158150634154.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox reassigned JBMESSAGING-269:
-----------------------------------

    Assignee: Tim Fox

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:30:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <16301779.1158150634309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox closed JBMESSAGING-269.
-------------------------------

    Resolution: Done

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <15729464.1158150752890.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox reopened JBMESSAGING-269:
---------------------------------

             

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <30570684.1158150753045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox updated JBMESSAGING-269:
--------------------------------

    Fix Version/s:     (was: 1.2.1)
                   1.2.0.Alpha1

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <645640.1158150753219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox closed JBMESSAGING-269.
-------------------------------

    Resolution: Done

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <12324762.1158150753347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox reopened JBMESSAGING-197:
---------------------------------

             

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <26546106.1158150753477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox updated JBMESSAGING-197:
--------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.1)

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <13458993.1158150753593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox closed JBMESSAGING-197.
-------------------------------

    Resolution: Done

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-425) Naming of
 Pipe and Distributed Pipe
Message-ID: <31441783.1158150871521.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox reopened JBMESSAGING-425:
---------------------------------

             

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-425) Naming of Pipe
 and Distributed Pipe
Message-ID: <32232880.1158150871622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox closed JBMESSAGING-425.
-------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.1)
       Resolution: Done

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-414) Simplify
 delivery hierarchy
Message-ID: <27584630.1158150871733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox reopened JBMESSAGING-414:
---------------------------------

             

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-414) Simplify
	delivery hierarchy
Message-ID: <24301907.1158150871853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox closed JBMESSAGING-414.
-------------------------------

    Fix Version/s: 1.2.0.Alpha1
    Fix Version/s:     (was: 1.2.1)
       Resolution: Done

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-192) Refactor
 Replicator so it
 won't be forced to provide noop implementation for Distributor's methods.
Message-ID: <27634439.1158151111542.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ]

Tim Fox reopened JBMESSAGING-192:
---------------------------------

             

> Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-192
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR2 (clustered)
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for
> Set handle(DeliveryObserver observer, Routable routable, Transaction transaction)
> However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport  implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor.
> Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <33414445.1158151111680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox reopened JBMESSAGING-197:
---------------------------------

             

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-199) Fix or
 mothball
 remotetopic so it does not require multiple deliveries per message
 reference
Message-ID: <19020182.1158151111815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ]

Tim Fox reopened JBMESSAGING-199:
---------------------------------

      Assignee: Tim Fox  (was: Ovidiu Feodorov)
             

> Fix or mothball remotetopic so it does not require multiple deliveries per message reference
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-199
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Re-implement remote topic to be a router with multiple channels - one per peer.
> This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-200) Complete XA
 transaction recovery
Message-ID: <9179614.1158151112082.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ]

Tim Fox reopened JBMESSAGING-200:
---------------------------------

             

> Complete XA transaction recovery
> --------------------------------
>
>                 Key: JBMESSAGING-200
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Complete XA transaction recovery.
> Most of the work is already in place for this.
> The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery.
> The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager.
> We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-228) Re-enable
 DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()
Message-ID: <22796986.1158151112262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ]

Tim Fox reopened JBMESSAGING-228:
---------------------------------

             

> Re-enable DistributedTopicTest testDistributedTopic_2() and  testDistributedTopic_4()
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-228
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and  testDistributedTopic_4(()
> because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run.
> Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-267) Re-enable
 distributed tests
Message-ID: <24494659.1158151112371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ]

Tim Fox reopened JBMESSAGING-267:
---------------------------------

             

> Re-enable distributed tests
> ---------------------------
>
>                 Key: JBMESSAGING-267
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0.
> These tests should be re-enabled and adjusted as necessary for the 1.2 release.
> All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <11074791.1158151112575.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox reopened JBMESSAGING-269:
---------------------------------

             

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-310) Investigate
 whether rw lock on ServerConnectionEndpoint is necessary
Message-ID: <28440246.1158151112774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ]

Tim Fox reopened JBMESSAGING-310:
---------------------------------

             

> Investigate whether rw lock on ServerConnectionEndpoint is necessary
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-310
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-332) Consider how
 best to factor paging logic out of channel state
Message-ID: <29443384.1158151112928.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ]

Tim Fox reopened JBMESSAGING-332:
---------------------------------

             

> Consider how best to factor paging logic out of channel state
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-332
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete 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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <28560559.1158151113164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Tim Fox reopened JBMESSAGING-361:
---------------------------------

             

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-404) Remove
 Channel::deliver(Receiver r) method
Message-ID: <8853461.1158151113296.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ]

Tim Fox reopened JBMESSAGING-404:
---------------------------------

             

> Remove Channel::deliver(Receiver r) method
> ------------------------------------------
>
>                 Key: JBMESSAGING-404
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This method is used to effectively do a synchronous receive() on a channel.
> The functionality could be more simply implemented by doing adding a MessageReference receive() method.
> This would also help in a clustered environment since we would have one less network RPC.
> Most of the complexity here is in updating tests.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-414) Simplify
 delivery hierarchy
Message-ID: <5163810.1158151113447.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox reopened JBMESSAGING-414:
---------------------------------

             

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-422) Move channel
 mapper logic into Queue, Topic, Subscription classes
Message-ID: <11416824.1158151113563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ]

Tim Fox reopened JBMESSAGING-422:
---------------------------------

             

> Move channel mapper logic into Queue, Topic, Subscription classes
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-422
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes.
> It's currently a bit of a mess.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-425) Naming of
 Pipe and Distributed Pipe
Message-ID: <167095.1158151113688.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox reopened JBMESSAGING-425:
---------------------------------

             

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-435) PointToPoint
 delivery with multiple consumers and selectors is broken
In-Reply-To: <23154601.1152954191989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14420618.1158151113834.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-435?page=all ]

Tim Fox reopened JBMESSAGING-435:
---------------------------------

             

> PointToPoint delivery with multiple consumers and selectors is broken
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-435
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery.
> If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer.
> Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:34 2006
From: jira-events at jboss.com (Michael Steiner (JIRA))
Date: Wed, 13 Sep 2006 08:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-351) method instance() in
 userPrincipal should be static
Message-ID: <29304742.1158151114106.JavaMail.jira@cloud.prod.atl2.jboss.com>

method instance() in userPrincipal should be static
---------------------------------------------------

                 Key: JBSEAM-351
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-351
             Project: JBoss Seam
          Issue Type: Patch
          Components: Core
    Affects Versions: 1.1
            Reporter: Michael Steiner
            Priority: Trivial




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Michael Steiner (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-351) method instance() in
 userPrincipal should be static
In-Reply-To: <29304742.1158151114106.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20936203.1158151234493.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-351?page=all ]

Michael Steiner updated JBSEAM-351:
-----------------------------------

    Attachment: patch.txt

add static before instance) method in userPrincipal component

> method instance() in userPrincipal should be static
> ---------------------------------------------------
>
>                 Key: JBSEAM-351
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-351
>             Project: JBoss Seam
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 1.1
>            Reporter: Michael Steiner
>            Priority: Trivial
>         Attachments: patch.txt
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-192) Refactor
 Replicator so it
 won't be forced to provide noop implementation for Distributor's methods.
Message-ID: <32537160.1158151234645.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ]

Tim Fox closed JBMESSAGING-192.
-------------------------------

    Resolution: Done

> Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-192
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR2 (clustered)
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for
> Set handle(DeliveryObserver observer, Routable routable, Transaction transaction)
> However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport  implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor.
> Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <28134410.1158151234770.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox closed JBMESSAGING-197.
-------------------------------

    Resolution: Done

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-199) Fix or mothball
 remotetopic
 so it does not require multiple deliveries per message reference
Message-ID: <17722908.1158151234902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ]

Tim Fox closed JBMESSAGING-199.
-------------------------------

    Resolution: Done

> Fix or mothball remotetopic so it does not require multiple deliveries per message reference
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-199
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Re-implement remote topic to be a router with multiple channels - one per peer.
> This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-200) Complete XA
 transaction recovery
Message-ID: <28226519.1158151235152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ]

Tim Fox closed JBMESSAGING-200.
-------------------------------

       Resolution: Done
    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.0.Beta1)

> Complete XA transaction recovery
> --------------------------------
>
>                 Key: JBMESSAGING-200
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Complete XA transaction recovery.
> Most of the work is already in place for this.
> The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery.
> The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager.
> We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-228) Re-enable
 DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()
Message-ID: <6104190.1158151235324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ]

Tim Fox closed JBMESSAGING-228.
-------------------------------

    Resolution: Done

> Re-enable DistributedTopicTest testDistributedTopic_2() and  testDistributedTopic_4()
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-228
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and  testDistributedTopic_4(()
> because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run.
> Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-267) Re-enable
	distributed tests
Message-ID: <19242404.1158151235449.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ]

Tim Fox closed JBMESSAGING-267.
-------------------------------

    Resolution: Done

> Re-enable distributed tests
> ---------------------------
>
>                 Key: JBMESSAGING-267
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0.
> These tests should be re-enabled and adjusted as necessary for the 1.2 release.
> All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <1657819.1158151235623.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox closed JBMESSAGING-269.
-------------------------------

    Resolution: Done

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-310) Investigate
 whether rw lock on ServerConnectionEndpoint is necessary
Message-ID: <29099168.1158151235746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ]

Tim Fox closed JBMESSAGING-310.
-------------------------------

    Fix Version/s:     (was: 1.2.1)
       Resolution: Done
    Fix Version/s: 1.2.0.Alpha1

> Investigate whether rw lock on ServerConnectionEndpoint is necessary
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-310
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-332) Consider how
 best to factor paging logic out of channel state
Message-ID: <17888418.1158151235859.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ]

Tim Fox closed JBMESSAGING-332.
-------------------------------

       Resolution: Done
    Fix Version/s:     (was: 1.2.1)
                   1.2.0.Alpha1

> Consider how best to factor paging logic out of channel state
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-332
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete 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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <11449048.1158151236029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Tim Fox closed JBMESSAGING-361.
-------------------------------

    Resolution: Done

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-404) Remove
 Channel::deliver(Receiver r) method
Message-ID: <31145692.1158151236140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ]

Tim Fox closed JBMESSAGING-404.
-------------------------------

    Resolution: Done

> Remove Channel::deliver(Receiver r) method
> ------------------------------------------
>
>                 Key: JBMESSAGING-404
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This method is used to effectively do a synchronous receive() on a channel.
> The functionality could be more simply implemented by doing adding a MessageReference receive() method.
> This would also help in a clustered environment since we would have one less network RPC.
> Most of the complexity here is in updating tests.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-414) Simplify
	delivery hierarchy
Message-ID: <28469463.1158151236260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox closed JBMESSAGING-414.
-------------------------------

    Resolution: Done

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-422) Move channel
 mapper logic into Queue, Topic, Subscription classes
Message-ID: <12827251.1158151236379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ]

Tim Fox closed JBMESSAGING-422.
-------------------------------

       Resolution: Done
    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.1)

> Move channel mapper logic into Queue, Topic, Subscription classes
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-422
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes.
> It's currently a bit of a mess.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-425) Naming of Pipe
 and Distributed Pipe
Message-ID: <10472306.1158151236508.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox closed JBMESSAGING-425.
-------------------------------

    Resolution: Done

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-435) PointToPoint
 delivery with multiple consumers and selectors is broken
In-Reply-To: <23154601.1152954191989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <194193.1158151236655.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-435?page=all ]

Tim Fox closed JBMESSAGING-435.
-------------------------------

       Resolution: Done
    Fix Version/s:     (was: 1.2.1)
    Fix Version/s: 1.2.0.Alpha1

> PointToPoint delivery with multiple consumers and selectors is broken
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-435
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery.
> If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer.
> Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:42:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:42:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1160047.1158151353622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Tim Fox updated JBMESSAGING-505:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:44:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:44:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-471) Set up a
 process to update messaging artifacts in repository
In-Reply-To: <16597753.1154477411320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16329387.1158151473733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-471?page=all ]

Tim Fox updated JBMESSAGING-471:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Set up a process to update messaging artifacts in repository
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-471
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-471
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ruel Loehr
>             Fix For: 1.2.0.Beta1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:44:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:44:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-264) Provide a
 mechanism to
 forward messages from one destination to another automatically
Message-ID: <7828318.1158151473885.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-264?page=all ]

Tim Fox updated JBMESSAGING-264:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> Provide a mechanism to forward messages from one destination to another automatically
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-264
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-264
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Chris DeLashmutt
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>
> I have had requests for this feature many times.  Basically, people seem to want to be able to have a component in messaging that will automatically forward messages to another destination.  This destination could be in the same messaging server or some remote destination. I'm thinking that the process must either be a daemon or an MDB, and since JBossMsg will also be available standalone I'm thinking we make it an MBean.  Another KEY to making this work is the 2PC stuff from Arjuna which isn't there yet (to make the pop and the push transactional).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:46:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:46:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-519) Transparent
	failover / HA
In-Reply-To: <21500267.1155575300585.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11318649.1158151592109.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=all ]

Tim Fox updated JBMESSAGING-519:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> Transparent failover / HA
> -------------------------
>
>                 Key: JBMESSAGING-519
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-519
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Tim Fox
>             Fix For: 1.2.0.Beta1
>
>
> Implement fully transparent failover for JMS clients as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:52:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-543) Use a file
 based transaction logger instead of logging in the database
Message-ID: <4467615.1158151954233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use a file based transaction logger instead of logging in the database
----------------------------------------------------------------------

                 Key: JBMESSAGING-543
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-543
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.2.1


Currently we are logging prepared state transactions in the database.

Instead, we should utilise a tried and tested transaction logger for performance reasons.

We should evaluate both JBoss TS objectstore, and HOWL to take this role

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:52:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-316) Backport of JGRP-217
Message-ID: <18775035.1158151954355.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport of JGRP-217
--------------------

                 Key: JGRP-316
                 URL: http://jira.jboss.com/jira/browse/JGRP-316
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.2.9 SP3 (2.2.9.3)
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.2.9 SP4




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:52:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-317) Backport of JGRP 302
 to JGroups 2.2.9 SP4
Message-ID: <23776931.1158151954629.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport of JGRP 302 to JGroups 2.2.9 SP4
-----------------------------------------

                 Key: JGRP-317
                 URL: http://jira.jboss.com/jira/browse/JGRP-317
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.2.9 SP3 (2.2.9.3)
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.2.9 SP4




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:54:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:54:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-318) Backport of JGRP-304
 to JGroups 2.2.9 SP4
Message-ID: <32101279.1158152077277.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport of JGRP-304 to JGroups 2.2.9 SP4
-----------------------------------------

                 Key: JGRP-318
                 URL: http://jira.jboss.com/jira/browse/JGRP-318
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.2.9 SP3 (2.2.9.3)
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.2.9 SP4




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:56:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-544) Use NBIO for
 connection model
Message-ID: <31643741.1158152193353.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use NBIO for connection model
-----------------------------

                 Key: JBMESSAGING-544
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-544
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.2.1


For throughput and scalability we need to use a non blocking IO model to provide connections between jms clients and server.

Unfortunately the JBoss remoting model does not currently allows this.

We can either drive JBoss Remoting to support this model (may take some time)

Or write out own connection functionality - this could be fairly straightforward if we use tools such as Apache MINA.

This would also solve the problem of providing a functional and performant multiplex transport.

Essentially we need a bidirectional channel between jms client and server.  On either end bytes can be read or witten in a non blocking fashion.

On top of that we can introduce simple framing in order to provide multiplex functionality.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:56:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-316) Backport of JGRP-217
In-Reply-To: <18775035.1158151954355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11507267.1158152193491.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-316?page=all ]

Bela Ban resolved JGRP-316.
---------------------------

    Resolution: Done

> Backport of JGRP-217
> --------------------
>
>                 Key: JGRP-316
>                 URL: http://jira.jboss.com/jira/browse/JGRP-316
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9 SP3 (2.2.9.3)
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.2.9 SP4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:02:32 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 09:02:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-318) Backport of JGRP-304
 to JGroups 2.2.9 SP4
In-Reply-To: <32101279.1158152077277.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3800669.1158152552808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-318?page=all ]

Bela Ban resolved JGRP-318.
---------------------------

    Resolution: Done

> Backport of JGRP-304 to JGroups 2.2.9 SP4
> -----------------------------------------
>
>                 Key: JGRP-318
>                 URL: http://jira.jboss.com/jira/browse/JGRP-318
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9 SP3 (2.2.9.3)
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.2.9 SP4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:10:32 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 09:10:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-317) Backport of JGRP 302
 to JGroups 2.2.9 SP4
In-Reply-To: <23776931.1158151954629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10227408.1158153032769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-317?page=all ]

Bela Ban resolved JGRP-317.
---------------------------

    Resolution: Done

> Backport of JGRP 302 to JGroups 2.2.9 SP4
> -----------------------------------------
>
>                 Key: JGRP-317
>                 URL: http://jira.jboss.com/jira/browse/JGRP-317
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9 SP3 (2.2.9.3)
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.2.9 SP4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:30:32 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 09:30:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-491) add document node
	type
Message-ID: <5435645.1158154232373.JavaMail.jira@cloud.prod.atl2.jboss.com>

add document node type
----------------------

                 Key: JBRULES-491
                 URL: http://jira.jboss.com/jira/browse/JBRULES-491
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:32:32 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 09:32:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-491) add document
	node type
In-Reply-To: <5435645.1158154232373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25953520.1158154352912.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-491?page=comments#action_12343258 ] 
            
Michael Neale commented on JBRULES-491:
---------------------------------------

should allow storage and classification of rule spec documentation (as it is JCR, after all !).

> add document node type
> ----------------------
>
>                 Key: JBRULES-491
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-491
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:26:41 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 13 Sep 2006 10:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1035) Integrate JSUnit
 with existing testing framework.
Message-ID: <24165503.1158157601048.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate JSUnit with existing testing framework.
-------------------------------------------------

                 Key: JBPORTAL-1035
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1035
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:38:36 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Wed, 13 Sep 2006 10:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-349) IssueTracker
 @LoggedIn missing @Interceptors annotation
In-Reply-To: <931519.1157705853664.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12927039.1158158316687.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-349?page=all ]

Stephan Bublava closed JBSEAM-349.
----------------------------------

    Resolution: Cannot Reproduce Bug

This works all right after all; I missed that there are two annotations that work together (@LoggedIn, @CheckLoggedIn)...

> IssueTracker @LoggedIn missing @Interceptors annotation
> -------------------------------------------------------
>
>                 Key: JBSEAM-349
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-349
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>
> I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:42:40 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12684766.1158158560914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Ovidiu Feodorov updated JBMESSAGING-541:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.0.1.GA)

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Wed Sep 13 10:44:34 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:44:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <26014130.1158158674859.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.0.Beta1)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:46:38 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Wed, 13 Sep 2006 10:46:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-61) Apache Tomcat 6.0
In-Reply-To: <21194316.1153309331365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21321978.1158158798924.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-61?page=comments#action_12343265 ] 
            
Remy Maucherat commented on JBWEB-61:
-------------------------------------

The finalized API is now implemented, featuring filtering. Some more minor details are not implemented yet.

> Apache Tomcat 6.0
> -----------------
>
>                 Key: JBWEB-61
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-61
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Remy Maucherat
>         Assigned To: Remy Maucherat
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:46:39 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:46:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <30956432.1158158799083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Ovidiu Feodorov updated JBMESSAGING-431:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.0.Beta1)

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ron Sigal
>             Fix For: 1.0.1.CR5
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:48:34 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <24633284.1158158914699.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-361:
-----------------------------------------

      Assignee: Ovidiu Feodorov  (was: Tim Fox)
             
I need to give it a litte bit more thought. I will close it myself.

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:48:34 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <288788.1158158914806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov updated JBMESSAGING-361:
----------------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.0.1.CR5

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:28:40 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:28:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6647851.1158161320658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov updated JBMESSAGING-542:
----------------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:28:40 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:28:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-277) Setting
 remoting lease period to -1 breaks ASF
Message-ID: <4393264.1158161320880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-277?page=all ]

Ovidiu Feodorov updated JBMESSAGING-277:
----------------------------------------

         Assignee: Ron Sigal
    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.0.Alpha1)

> Setting remoting lease period to -1 breaks ASF
> ----------------------------------------------
>
>                 Key: JBMESSAGING-277
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-277
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> LeasePeriod == -1 is supposed to disable remoting leasing.
> However, setting LeasePeriod to -1 breaks ASF. TCK tests don't pass anymore.
> Whoever fixes this problem, should add a functional test so the Messaging testsuite catches this problem before TCK does.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:30:43 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:30:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <5987736.1158161443852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov updated JBMESSAGING-302:
----------------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
         Assignee: Clebert Suconic
    Fix Version/s: 1.0.1.CR5

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:30:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:30:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-287)
 RemotingTest.testConnectionListener() invalid
Message-ID: <22527012.1158161444064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ]

Ovidiu Feodorov updated JBMESSAGING-287:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
         Assignee: Ron Sigal  (was: Tim Fox)
    Fix Version/s:     (was: 1.2.0.Alpha1)

> RemotingTest.testConnectionListener() invalid
> ---------------------------------------------
>
>                 Key: JBMESSAGING-287
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. 
> After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:55:34 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 11:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-3652) Add EULA to licenses
 folder of distribution
Message-ID: <33451974.1158162934873.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Ryan Campbell moved JBQA-465 to JBAS-3652:
------------------------------------------

    Project: JBoss Application Server  (was: JBoss QA)
        Key: JBAS-3652  (was: JBQA-465)

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Ryan Campbell
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:55:35 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 11:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3652) Add EULA to licenses
 folder of distribution
Message-ID: <2423287.1158162935060.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Ryan Campbell updated JBAS-3652:
--------------------------------

         Assignee: Rajesh Rajasekaran  (was: Ryan Campbell)
    Fix Version/s: JBossAS-4.0.5.GA

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:55:35 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 11:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3652) Add EULA to licenses
 folder of distribution
Message-ID: <5831114.1158162935219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Ryan Campbell updated JBAS-3652:
--------------------------------

    Priority: Critical  (was: Major)

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:07:34 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 12:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-762) Configuration object
 enhancements
In-Reply-To: <17732187.1157804023738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21549443.1158163654392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-762?page=all ]

Manik Surtani closed JBCACHE-762.
---------------------------------

      Assignee: Manik Surtani  (was: Hany Mesha)
    Resolution: Done

> Configuration object enhancements
> ---------------------------------
>
>                 Key: JBCACHE-762
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-762
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> 1.  Why isn't there a CacheFactory.createCache() (using the default configuration)
> 2.  I think it would be useful to have a static method in Configuration which returns the default config, so we could do: Cache c=new DefaultCacheFactory().createCache(Configuration.getDefault())
> 3.  Configuration should have a copy() or clone() method, so we can reuse a config, and make small modifications
> 4.  Make Configuration serializable (ship them around ?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:30:40 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Wed, 13 Sep 2006 12:30:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-348) IssueTracker
 example uses nonexisting annotation (Within)
In-Reply-To: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33230009.1158165040379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-348?page=all ]

Stephan Bublava updated JBSEAM-348:
-----------------------------------

    Attachment: jbseam-348-patch.txt

The attached patch fixes the build error.

> IssueTracker example uses nonexisting annotation (Within)
> ---------------------------------------------------------
>
>                 Key: JBSEAM-348
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>         Attachments: jbseam-348-patch.txt
>
>
> org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Wed Sep 13 12:36:35 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Wed, 13 Sep 2006 12:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <8125495.1158165395624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ]

Madhusudhan Konda updated JBMESSAGING-407:
------------------------------------------

    Attachment: xarecovery-patch.txt
                artifacts.zip

Please find the patch file with this message. I have also attached the compressed src and tests folders, just in case. 
Testing is something which I had a bit of problem - as to how to simulate the server crash etc. Please see the tests/build.xml where I descibed the testing process. I am sure you'll have issues :)
Thanks
Madhu

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:36:35 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Wed, 13 Sep 2006 12:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-352) debug.seam should
 be able to display interceptors for a given component
Message-ID: <27074460.1158165395733.JavaMail.jira@cloud.prod.atl2.jboss.com>

debug.seam should be able to display interceptors for a given component
-----------------------------------------------------------------------

                 Key: JBSEAM-352
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-352
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
    Affects Versions: 1.0.1
            Reporter: Stephan Bublava
            Priority: Trivial


It would be great, if debug.seam would display all interceptors that are enabled for a component. This just requires two getter methods for Component.interceptors and Component.clientSideInterceptors.

I can deliver a patch if desired...

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:38:40 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 13 Sep 2006 12:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-350) High conversation
 state number causes ui:repeat to show a single item
In-Reply-To: <852986.1157870850894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24397575.1158165520360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-350?page=all ]

Gavin King closed JBSEAM-350.
-----------------------------

    Resolution: Rejected

Not a bug in Seam. (Facelets, maybe.)

> High conversation state number causes ui:repeat to show a single item
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-350
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-350
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: CentOS i686, JDK 1.5.0_06-b05, MyFaces 1.1.3, Facelets 1.1.11, JBoss 4.0.4 with EJB3 RC8 FD
>            Reporter: Basel Al-Mustafa
>
> When the conversation state number goes up to around 4750 the ui:repeat element stops showing the compete list of items. Rather than that only a single item is displayed even though both of the database query and the SLSB page action return several items. The production server log and the source code can be found in the associated JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:38:40 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Wed, 13 Sep 2006 12:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <32423679.1158165520519.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12343270 ] 
            
Madhusudhan Konda commented on JBMESSAGING-407:
-----------------------------------------------

There has been additions to the *persistence.xml file. Have a look in the attached sybase-perisistence.xml

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:40:44 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 13 Sep 2006 12:40:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-598) add timeout config
 per client invocation
Message-ID: <29603001.1158165644827.JavaMail.jira@cloud.prod.atl2.jboss.com>

add timeout config per client invocation
----------------------------------------

                 Key: JBREM-598
                 URL: http://jira.jboss.com/jira/browse/JBREM-598
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
            Priority: Minor
             Fix For: 2.2.0.Beta1 (Bluto)


Would like to be able to control timeout per invocation.  Probably best way to do this is pass as part of metadata map passed to the invoke method within Client.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:06:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:06:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30861468.1158167199869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Scott M Stark updated JBAS-3650:
--------------------------------

    Attachment: jbosssx.jar

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:19:43 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
Message-ID: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
---------------------------------------------------------------------------------

                 Key: JBAS-3653
                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA
         Attachments: example2.ldif

For a schema like example2.ldif and a configuration like:
      testLdapExample22 {
         org.jboss.security.auth.spi.LdapExtLoginModule
            java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
            java.naming.provider.url="ldap://lamia/"
            java.naming.security.authentication=simple
            bindDN="cn=Root,dc=jboss,dc=org"
            bindCredential=secret1
            baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
            baseFilter="(uid={0})"
            rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
            roleFilter="(uid={0})"
            roleAttributeID="memberOf"
            roleAttributeIsDN="true"
            roleNameAttributeID="cn"
            roleRecursion=0
      };

Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:19:44 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:19:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14717137.1158167984059.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark updated JBAS-3653:
--------------------------------

    Attachment: example2.ldif

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:24:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:24:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9863809.1158168279422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark updated JBAS-3653:
--------------------------------

    Attachment:     (was: example2.ldif)

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:24:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:24:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7428488.1158168279532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark updated JBAS-3653:
--------------------------------

    Attachment: example2.ldif

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:24:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:24:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10020637.1158168279686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Scott M Stark updated JBAS-3650:
--------------------------------

    Attachment:     (was: jbosssx.jar)

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: JBoss QA Lead
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:29:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3112431.1158168581937.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Scott M Stark updated JBAS-3650:
--------------------------------

    Attachment: jbosssx.jar

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: JBoss QA Lead
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:43:33 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:43:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3653) Ldap*LoginModule fail
 to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29816080.1158169413801.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark closed JBAS-3653.
-------------------------------

    Resolution: Done

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:43:33 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:43:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-7) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
Message-ID: <7485782.1158169413906.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
---------------------------------------------------------------------------------

                 Key: SECURITY-7
                 URL: http://jira.jboss.com/jira/browse/SECURITY-7
             Project: JBoss Security
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: 2.0


For a schema like example2.ldif and a configuration like:
      testLdapExample22 {
         org.jboss.security.auth.spi.LdapExtLoginModule
            java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
            java.naming.provider.url="ldap://lamia/"
            java.naming.security.authentication=simple
            bindDN="cn=Root,dc=jboss,dc=org"
            bindCredential=secret1
            baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
            baseFilter="(uid={0})"
            rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
            roleFilter="(uid={0})"
            roleAttributeID="memberOf"
            roleAttributeIsDN="true"
            roleNameAttributeID="cn"
            roleRecursion=0
      };

Only one role is being pulled from the cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:43:34 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 13 Sep 2006 13:43:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-257) Test extender test
 in a scoped environment
Message-ID: <28967632.1158169414099.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-257?page=comments#action_12343272 ] 
            
Kabir Khan commented on JBAOP-257:
----------------------------------

Methods and fields now work - still need to test constructors

The tests do all compinations of

* Base, global sar with classes loaded/classes not loaded
* Child, scoped sar with parent delegation/no parent delegation

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:55:38 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 13:55:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2283) Custom header based
	authentication
Message-ID: <30256412.1158170138795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2283?page=all ]

Anil Saldhana closed JBAS-2283.
-------------------------------

    Resolution: Done

> Custom header based authentication
> ----------------------------------
>
>                 Key: JBAS-2283
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2283
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.CR1
>
>         Attachments: B19006.pdf, B19008v2.pdf, B19013.pdf
>
>
> We have been getting requests for custom authentication methods based around prorpietary headers/logic. The following attachments describe the oracle COREid product.
> B19006.pdf - high level overview of how the product works
> B19008v2.pdf - details of authentication protocol (p. 85 - 92)
> B19013.pdf - documentation about API
> Likely the most important part is assuming a user is who the HTTP_OBLIX_UID header says they are. The COREid server and the firewall should protect the server from unauthorized 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

        


From jira-events at jboss.com  Wed Sep 13 13:55:39 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 13:55:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2283) Custom header based
 authentication
Message-ID: <6182351.1158170139069.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2283?page=comments#action_12343273 ] 
            
Anil Saldhana commented on JBAS-2283:
-------------------------------------

$> ant tomcat-federation-tests
....
    [junit] Running org.jboss.test.web.security.CustomHeaderAuthTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.015 sec



> Custom header based authentication
> ----------------------------------
>
>                 Key: JBAS-2283
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2283
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.CR1
>
>         Attachments: B19006.pdf, B19008v2.pdf, B19013.pdf
>
>
> We have been getting requests for custom authentication methods based around prorpietary headers/logic. The following attachments describe the oracle COREid product.
> B19006.pdf - high level overview of how the product works
> B19008v2.pdf - details of authentication protocol (p. 85 - 92)
> B19013.pdf - documentation about API
> Likely the most important part is assuming a user is who the HTTP_OBLIX_UID header says they are. The COREid server and the firewall should protect the server from unauthorized 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

        


From jira-events at jboss.com  Wed Sep 13 14:07:37 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 14:07:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-7) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <7485782.1158169413906.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23562130.1158170857776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-7?page=all ]

Scott M Stark closed SECURITY-7.
--------------------------------

    Resolution: Done

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: SECURITY-7
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-7
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 2.0
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:06:37 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Wed, 13 Sep 2006 16:06:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
Message-ID: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>

The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
----------------------------------------------------------------------------

                 Key: JBAS-3654
                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final,  JBossAS-4.0.3RC2,  JBossAS-4.0.3RC1
            Reporter: Sakthi Samabsivam
         Assigned To: Dimitris Andreadis


When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.

for example.  I have two ears example1. ear and example2.ear.

I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..

So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml

 <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>

This depends is working till jboss 4.0.1

It fails in 4.0.3 SP1 , 4.0.4 GA

15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
ment:war=crimeportal.war,id=-1360680885
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
e: (javax.security.jacc.PolicyContextException: Operation not allowed)
        at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)

        at org.jboss.web.WebModule.startModule(WebModule.java:68)
        at org.jboss.web.WebModule.startService(WebModule.java:46)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:428)
        at org.jboss.system.ServiceController.start(ServiceController.java:446)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy21.start(Unknown Source)
        at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
        at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy9.deploy(Unknown Source)
        at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:319)
        at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:507)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:192)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:265)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:428)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy4.start(Unknown Source)
        at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
        at org.jboss.Main.boot(Main.java:187)
        at org.jboss.Main$1.run(Main.java:438)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
        at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:201)
        at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
ossPolicyConfiguration.java:160)
        at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)

        ... 94 more
Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
tion: linkConfiguration from state:inService
        at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
        at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:196)
        ... 96 more
15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

--- MBeans waiting for other MBeans ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)

  I Depend On:
    jboss.j2ee:url='FiboApp.ear',service=EARDeployment

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)

  I Depend On:
    jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:42:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 16:42:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3655) Constructors in JMX
 AuthenticationInterceptor and AuthorizationInterceptor
Message-ID: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>

Constructors in JMX AuthenticationInterceptor and AuthorizationInterceptor
--------------------------------------------------------------------------

                 Key: JBAS-3655
                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMX, Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
	at java.lang.Class.getConstructor0(Class.java:2678)
	at java.lang.Class.getConstructor(Class.java:1629)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 

.....

2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
	at java.lang.Class.getConstructor0(Class.java:2678)
	at java.lang.Class.getConstructor(Class.java:1629)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:52:30 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 13 Sep 2006 16:52:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3656) Disconnect
 HAPartition channel upon failure in startService()
Message-ID: <12832750.1158180750351.JavaMail.jira@cloud.prod.atl2.jboss.com>

Disconnect HAPartition channel upon failure in startService()
-------------------------------------------------------------

                 Key: JBAS-3656
                 URL: http://jira.jboss.com/jira/browse/JBAS-3656
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1


If an exception is thrown in ClusterPartition/HAPartition startService() after the channel is connected, the channel must be disconnected, or we've left a zombie member of the group.  Particularly in 4.0.x where the ServiceController will not undeploy a service that fails in start().

Need to ensure stopService() properly handles a disconnected channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:58:32 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 16:58:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3336963.1158181112987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Anil Saldhana updated JBAS-3655:
--------------------------------

    Summary: Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker  (was: Constructors in JMX AuthenticationInterceptor and AuthorizationInterceptor)

It should be:
catch (Throwable t)
         {
            log.warn("Failed to invoke ctor(MBeanInvoker) for: "
               + interceptorClass, t); 
            // Try the default ctor
            interceptor = (Interceptor) interceptorClass.newInstance();
            log.warn("Success:default ctr used to construct:"+ interceptorClass);
         }

rather than log.debug

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:04:31 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 17:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25676936.1158181471720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Anil Saldhana updated JBAS-3655:
--------------------------------

    Fix Version/s:     (was: JBossAS-5.0.0.Beta)

Not applicable to HEAD.

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:04:31 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 17:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28756764.1158181471858.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Anil Saldhana closed JBAS-3655.
-------------------------------

    Resolution: Done

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:22:34 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Wed, 13 Sep 2006 17:22:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <21333807.1158182554359.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343280 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Is this license used by any of the thirdparty libs, so they can be automatically pulled when downloading the thirdparty, by JBOSSBUILD.
If not i can upload to the repository and package it in the build output getting it directly from the repository.


> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:26:34 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 17:26:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <29271369.1158182794714.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343281 ] 
            
Ryan Campbell commented on JBAS-3652:
-------------------------------------

For now, this is just for the AS itself, not libraries.  This should likely go in whatever module we keep the copyright.txt file, and be copied to docs/licenses in the build/build-dist.xml.

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:34:34 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 17:34:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1004) Jboss Portal to
 support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13926727.1158183274428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ]

Sverker Abrahamsson updated JBPORTAL-1004:
------------------------------------------

    Attachment: jboss-portal-2.4.patch

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:34:34 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 17:34:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1004) Jboss Portal to
 support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26562685.1158183274643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ]

Sverker Abrahamsson updated JBPORTAL-1004:
------------------------------------------

    Attachment: new.files.zip

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:12:31 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
Message-ID: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1036
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:12:31 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 18:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15105155.1158185551754.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343282 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

Ok, after a lot of working with the debugger and following the flow I've made the neccesary changes. It works beautifully now, if I may say it myself.

The attached patch and files are on the 2.4 branch but shouldn't bee too hard to port to head once we've agreed on a few design questions that needs to be discussed.

With this patch, if a war file contains an *-object.xml which creates a portal without any parent ref, then a new context is created and the virtual-host and context path settings of the war file is bound to it. The id of the context is either the application name given by jboss-app.xml or derived from the virtual-host and context path. I haven't updated Transient PortalObjectContainer yet with the new functionality, just added the method declarations to make it compile.

Next, after the deployment had been taken care of, the request processing had to change slightly. The servername is fetched from the request in PortalServlet and stored in ServletRequestContext. The CommandFactory classes are updated so that doMapping gets the portalHost parameter.

DefaultPortalCommandFactory caused a strange behaviour, if a link was wrong, e.g. spelled wrong or so, then it sent the request to the default portal. That resulted in that suddenly the default portal markup could appear in a middle of a page. I changed that so that if the CommandFactory chain failed to map the request, then a 404 response is sent via the new class ErrorResponseCommand. However, this more or less obsoletes this class. Instead CoreController should create a ErrorResponseCommand if cmd is null after passing through the CommandFactory chain.

DelegatingCommandFactoryService was modified to send a request to / to PortalObjectCommandFactory, it's doing that by shortcutting the PathParser but I think it's ok.

PortalObjectCommandFactory is modified to look up the context by using portalHost and portalContextPath. If a context can't be found using those data, then it tries to look up on just portalContextPath (for those cases where the webapp didn't specify any virual-host but just bind to the default name) and if still noting found then the default context is used.

CMSObjectCommandFactory was modified to send a ErrorResponseCommand with 404 if it couldn't find the file specified which is the correct behaviour. As it was before the default portal could suddenly appear in the middle of the page which looked quite strange. Also, it now respond with code 500 if an internal error occurs.

The same for StreamContentCommand. I noticed another thing, the file was first looked up in CMSObjectCommandFactory and then again in StreamContentCommand. I added a shortcut so that it could be passed along and hence eliminating the second lookup.

 A minor change had to be done on the security, in JACCPortalAuthorizationManager and JACCPortalAuthorizationManagerFactory as the configured roles have to be managed per context id (i.e. war file).

The last big change was on how theme is handled. Before it just rendered an url, e.g. /portal-core/themes/phalanx/portal_style.css which didnt work because that path didn't exsist in my virtual-host. Instead I created a new CommandFactory which is bound to /theme so if I have a portal bound to the url http://portaltest.abrahamsson.com which use theme Npalanx then the stylesheet is loaded from http://portaltest.abrahamsson.com/theme/themes/phalanx/portal_style.css 

Julien and Roy, please read through these proposed changes and let me know what you think.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:14:32 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:14:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22686411.1158185672206.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=comments#action_12343283 ] 
            
Julien Viet commented on JBPORTAL-1036:
---------------------------------------

we should probably use : org.jboss.portal.portlet.container. + class.getName().replace('.','_');

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.2.2 Final, 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:14:32 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 13 Sep 2006 18:14:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3649) Startup switches
 should set the new JGroups system properties
In-Reply-To: <13306029.1158112843780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9087772.1158185672522.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3649?page=all ]

Brian Stansberry closed JBAS-3649.
----------------------------------

       Resolution: Done
    Fix Version/s: JBossAS-4.0.5.GA

Fixed for 4.0.5.GA as well.  That release ships with JGroups 2.2.7 which internally still only uses the old bind.address property.  But the -b switch will set both versions of the property, so if a user upgrades to JGroups 2.4 or higher or uses the new property in a config file, it will be respected.

> Startup switches should set the new JGroups system properties
> -------------------------------------------------------------
>
>                 Key: JBAS-3649
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3649
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> JGroups has created a more formalized system for the names of the system properties it uses (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps).  We need to ensure that when the JBoss AS command-line switches are used, the new system properties get set:
> -b jgroups.bind_addr
> -u  jgroups.udp.mcast_addr
> The old properties will be set as well to ensure legacy config files still work.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:18:31 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:18:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31581100.1158185911045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=all ]

Julien Viet reassigned JBPORTAL-1036:
-------------------------------------

    Assignee: Chris Laprun  (was: Julien Viet)

assigning it to the right person

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.2.2 Final, 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:18:30 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:18:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1033)
 PortletContainer added logging causes class loading issues.
In-Reply-To: <4364937.1158098671693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14160142.1158185910878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1033?page=all ]

Julien Viet resolved JBPORTAL-1033.
-----------------------------------

    Resolution: Duplicate Issue

oops duplicate, I keep the other as the description is more detailled.

> PortletContainer added logging causes class loading issues.
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1033
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1033
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1
>
>
> In PortletContainer constructor:
> this.portletLog = Logger.getLogger(metaData.getClassName());
> causes Log4J to be loaded in several different class loaders causing CCEs.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:36:31 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:36:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2131606.1158186991194.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343289 ] 
            
Julien Viet commented on JBPORTAL-1004:
---------------------------------------

Looking at it quickly, you need to provide a solution that does not require modifications of the PortalObject concepts.

Why not map virtual host to portal instead ?

The PortalObject : Context is supposed to be unique and the root of the portal object tree.


> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:36:31 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 13 Sep 2006 18:36:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7780323.1158186991301.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=comments#action_12343290 ] 
            
Chris Laprun commented on JBPORTAL-1036:
----------------------------------------

See also http://jira.jboss.com/jira/browse/JBPORTAL-1020

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.2.2 Final, 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:10:31 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 13 Sep 2006 19:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1037) Tool based
 mechanism (e.g. Eclipse plugin) for modifying portal metadata
Message-ID: <27943353.1158189031292.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tool based mechanism (e.g. Eclipse plugin) for modifying portal metadata
------------------------------------------------------------------------

                 Key: JBPORTAL-1037
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1037
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: William DeCoste
            Priority: Optional


This is a request from Intuit. I can gather more detailed requirements as needed - Bill

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:28:33 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 13 Sep 2006 19:28:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1038) Allow export of
 database to xml
Message-ID: <24585280.1158190113259.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow export of database to xml
-------------------------------

                 Key: JBPORTAL-1038
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1038
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4 Final
            Reporter: William DeCoste
            Priority: Minor


This feature was requested by Intuit.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:30:29 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 13 Sep 2006 19:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1038) Allow export
 of database to xml
In-Reply-To: <24585280.1158190113259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21483287.1158190229919.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1038?page=comments#action_12343292 ] 
            
William DeCoste commented on JBPORTAL-1038:
-------------------------------------------

They want to be able to move a configuration from one environment to another (development to test to production)

> Allow export of database to xml
> -------------------------------
>
>                 Key: JBPORTAL-1038
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1038
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final
>            Reporter: William DeCoste
>            Priority: Minor
>
> This feature was requested by Intuit.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:54:33 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 19:54:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18512665.1158191673533.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343293 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

Well, the idea I had was that since a different web application is essentially a different context then create new contexts under the root would be the right way to go. If you have only one context then you can optimize it away, it doesn't add any value to the data model.

Not that it matters though, I think it should be possible to map ContextPath to Portal instead. The only issue I can think of from the top of my head is how to decide which is the default portal if several portals is deployed in the same *-object.xml without parent references but that can be handled by being a bit picky when deploying.

I don't really care which, the only thing I care about is the functionality in the end.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 21:22:29 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Wed, 13 Sep 2006 21:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-492) Debug views should
 remember if they are + or 1
Message-ID: <9721054.1158196949067.JavaMail.jira@cloud.prod.atl2.jboss.com>

Debug views should remember if they are + or 1
----------------------------------------------

                 Key: JBRULES-492
                 URL: http://jira.jboss.com/jira/browse/JBRULES-492
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 3.1-m1


When you are continually using the debug views its annoying to keep pressing the + to expand, it would be nice if it stayed expanded once it was selected.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 21:26:30 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Wed, 13 Sep 2006 21:26:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-493) Remember selected
 working memory for debug views
Message-ID: <26521911.1158197190038.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remember selected working memory for debug views
------------------------------------------------

                 Key: JBRULES-493
                 URL: http://jira.jboss.com/jira/browse/JBRULES-493
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 3.1-m1


When you select working memory it should remember that instance, so when you are propagating through the network you shouldn't have to keep re-selecting it to view data. Better yet we should have another debug view that collects working memory instances as it "realises" them during debug runtime, the current one is highlighed and a different current can easily be selected.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 22:53:43 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Wed, 13 Sep 2006 22:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-494) Linked Tuple
Message-ID: <15357564.1158202423100.JavaMail.jira@cloud.prod.atl2.jboss.com>

Linked Tuple
------------

                 Key: JBRULES-494
                 URL: http://jira.jboss.com/jira/browse/JBRULES-494
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1


Instead of cloning FactHandle['] arrays, which is expensive, as its creating factorial too many objects, we shoudl instead looked to some sort of linked list; so that it doesn't need to copy the information of the parents.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 00:37:36 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 14 Sep 2006 00:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-183) write release guide
Message-ID: <6529297.1158208656584.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-183?page=all ]

Alejandro Guizar updated BPEL-183:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 2)

> write release guide
> -------------------
>
>                 Key: BPEL-183
>                 URL: http://jira.jboss.com/jira/browse/BPEL-183
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> QA requires a release guide in the wiki area. Use http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmReleaseGuide as a template.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 00:37:36 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 14 Sep 2006 00:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-186) Write a blog entry
 about the beta release
Message-ID: <24862724.1158208656709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-186?page=all ]

Alejandro Guizar updated BPEL-186:
----------------------------------

          Summary: Write a blog entry about the beta release  (was: Write a blog entry about the 1.1 release)
    Fix Version/s: jBPM BPEL 1.1 beta 2
                       (was: jBPM BPEL 1.1 beta 3)

> Write a blog entry about the beta release
> -----------------------------------------
>
>                 Key: BPEL-186
>                 URL: http://jira.jboss.com/jira/browse/BPEL-186
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 02:05:38 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Thu, 14 Sep 2006 02:05:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-353) @Interceptors
 meta-annotation needs @Target(TYPE)
Message-ID: <14552072.1158213938068.JavaMail.jira@cloud.prod.atl2.jboss.com>

@Interceptors meta-annotation needs @Target(TYPE)
-------------------------------------------------

                 Key: JBSEAM-353
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-353
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Documentation
    Affects Versions: 1.0.1
            Reporter: Stephan Bublava
            Priority: Minor


The @Interceptors meta-annotation only works with @Target(TYPE). If you want to intercept certain methods only, two cooperating annotations are required (as demonstrated by the issue tracker example in CVS, which uses @LoggedIn and @CheckLoggedIn).

Since this is not obvious (at least to me), it should be explained in the documentation (chapter 2.6. Seam interceptors).

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:41:37 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 03:41:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-16) scratchdir fails
 for multi-user installs
Message-ID: <32023555.1158219697540.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-16?page=comments#action_12343300 ] 
            
Luc Texier commented on JBWEB-16:
---------------------------------

I had to investigate this problem for a customer.

The issue is that the last folder at the end of the path is not created automatically. 

so if you want Tomcat to write to e.g. /home/myuser/jboss/work, /work must exist already


Note: If a path is not specified as in the default configuration, "something" is creating the "/work" directory...what? I dunno



> scratchdir fails for multi-user installs
> ----------------------------------------
>
>                 Key: JBWEB-16
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-16
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat Module
>    Affects Versions:  JBossWeb embedded - AS 4.0.1
>            Reporter: Norman Richards
>         Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8).   Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis.  Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. 
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:43:37 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 03:43:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <24208115.1158219817437.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Luc Texier updated JBAS-3641:
-----------------------------

    Security: Public  (was: JBoss Partner)

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:57:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 14 Sep 2006 03:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-313) MultiplexerTests
 don't work with TCP configuration
In-Reply-To: <15805211.1158066153671.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20140105.1158220657346.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-313?page=comments#action_12343301 ] 
            
Bela Ban commented on JGRP-313:
-------------------------------

They actually work with "tcp" (TCP), but there are failures in "tcp-nio" (TCP_NIO). Probably due to TCP_NIO not being stopped correctly in tearDown(), so that new tests conflict with leftover sockets from previous tests: need to investigate TCP_NIO.stop()

> MultiplexerTests don't work with TCP configuration
> --------------------------------------------------
>
>                 Key: JGRP-313
>                 URL: http://jira.jboss.com/jira/browse/JGRP-313
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> UDP works 100%, however, some of the tests fail with a TCP configuration

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:57:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 03:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <19090049.1158220657571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis reassigned JBAS-3641:
----------------------------------------

    Assignee: Dimitris Andreadis

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:11:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:11:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28749848.1158221498422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis reopened JBAS-3655:
--------------------------------------

             
I don't understand this "fix" at all. An interceptor of this type can either have a 
CTOR(MBeanInvoker)
or
CTOR()

The code simply tries the first one, then the second one. If the interceptor cannot be constructed at all, then this is something to be reported. There is no need to log WARN messages or legthy exceptions.

I changed this to:

         catch (Throwable t)
         {
            log.debug("Could not invoke CTOR(MBeanInvoker) for '"
                  + interceptorClass + "', trying default CTOR: " + t.getMessage()); 
            
            // Try the default ctor
            interceptor = (Interceptor) interceptorClass.newInstance();
         }

Anil, if you want to completely get rid of the debug message, add a CTOR(MBeanInvoker) to

org.jboss.jmx.connector.invoker.AuthorizationInterceptor
org.jboss.jmx.connector.invoker.AuthenticationInterceptor




> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:11:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:11:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24428068.1158221498627.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis updated JBAS-3655:
-------------------------------------

    Issue Type: Task  (was: Feature Request)

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:11:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:11:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15528051.1158221498778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis updated JBAS-3655:
-------------------------------------

    Affects Version/s:     (was: JBossAS-4.0.4.GA)
                       JBossAS-4.0.5.CR1

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:39:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:39:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Reduce logging for
 the construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8884185.1158223177300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis updated JBAS-3655:
-------------------------------------

              Summary: Reduce logging for the construction of interceptor in ModelMBeanInvoker  (was: Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker)
        Fix Version/s: JBossAS-5.0.0.Beta
                       JBossAS-3.2.8.SP2
    Affects Version/s: JBossAS-3.2.8.SP1

> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:39:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:39:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3655) Reduce logging for
 the construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16546171.1158223177412.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3655?page=comments#action_12343303 ] 
            
Dimitris Andreadis commented on JBAS-3655:
------------------------------------------

I committed this to all branches


> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:05:37 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 05:05:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-16) scratchdir fails for
 multi-user installs
Message-ID: <30256772.1158224737038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-16?page=all ]

Luc Texier updated JBWEB-16:
----------------------------

    Comment: was deleted

> scratchdir fails for multi-user installs
> ----------------------------------------
>
>                 Key: JBWEB-16
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-16
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat Module
>    Affects Versions:  JBossWeb embedded - AS 4.0.1
>            Reporter: Norman Richards
>         Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8).   Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis.  Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. 
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:07:39 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 05:07:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-16) scratchdir fails
 for multi-user installs
Message-ID: <24746508.1158224859319.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-16?page=comments#action_12343306 ] 
            
Luc Texier commented on JBWEB-16:
---------------------------------

I removed my last comment which was erroneous

scratchdir is used only when compiling jsp pages

what you might consider is the following option instead
JAVA_OPTS="$JAVA_OPTS -Dcatalina.base=/tmp/catalina"

the server will then created the /work directory in there


> scratchdir fails for multi-user installs
> ----------------------------------------
>
>                 Key: JBWEB-16
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-16
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat Module
>    Affects Versions:  JBossWeb embedded - AS 4.0.1
>            Reporter: Norman Richards
>         Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8).   Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis.  Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. 
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:13:46 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Thu, 14 Sep 2006 05:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <11620650.1158225226023.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12343307 ] 
            
Madhusudhan Konda commented on JBMESSAGING-407:
-----------------------------------------------

BTW, you need to add the following changes to conf/jbossjta-properties.xml:

<properties depends="arjuna" name="jta">
...
<property   name="com.arjuna.ats.jta.recovery.XAResourceRecoveryMessaging" value="org.jboss.jms.recovery.MessagingXAResourceRecovery;xaConnFac=XAConnectionFactory"/>
<property name="com.arjuna.ats.jta.xaRecoveryNode" value="*" />

..
</properties>

Note: the above properties MUST go under "jta" section (not the expected recoverymanager)

And

<properties depends="arjuna" name="recoverymanager">
..
 <property name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
...
</properties>



> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:13:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 05:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <10499285.1158225226264.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3641?page=comments#action_12343308 ] 
            
Dimitris Andreadis commented on JBAS-3641:
------------------------------------------

Thanks John.

I'll commit this to all brances, but can you please verify it works with the latest jboss-4.0.5.CR1 ?

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:13:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 05:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <6792224.1158225226489.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis updated JBAS-3641:
-------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                   JBossAS-3.2.8.SP2

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:15:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 05:15:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <3224461.1158225346776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis updated JBAS-3641:
-------------------------------------

    Affects: [Compatibility/Configuration]

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:15:46 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Thu, 14 Sep 2006 05:15:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <17557757.1158225346945.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12343309 ] 
            
Madhusudhan Konda commented on JBMESSAGING-407:
-----------------------------------------------

One of the things missing is - using the JMSProvderAdapter to fetch the jms provider as Adrian was using in his MQ recovery. I am working on this.

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 06:03:45 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 14 Sep 2006 06:03:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
In-Reply-To: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28648335.1158228225072.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3654?page=all ]

Adrian Brock updated JBAS-3654:
-------------------------------

    Issue Type: Feature Request  (was: Bug)

Changed to a feature request.

It has never been possible to depend upon an EAR
since an EAR is not a service.

Nor does the EAR lifecycle relate to its components in any direct way
beyond the initial construction of the subdeployments.

I'm pretty sure this is explained in the WIKI somewhere
along with the related FAQ about trying to depend upon JSR77 mbeans. :-)

> The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC1,  JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Dimitris Andreadis
>
> When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
> for example.  I have two ears example1. ear and example2.ear.
> I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
> So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml
>  <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
> This depends is working till jboss 4.0.1
> It fails in 4.0.3 SP1 , 4.0.4 GA
> 15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
> ment:war=crimeportal.war,id=-1360680885
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
> e: (javax.security.jacc.PolicyContextException: Operation not allowed)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
>         at org.jboss.web.WebModule.startModule(WebModule.java:68)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at org.jboss.system.ServiceController.start(ServiceController.java:446)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy21.start(Unknown Source)
>         at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy9.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
> tScanner.java:319)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
> canner.java:507)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
> doScan(AbstractDeploymentScanner.java:192)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
> bstractDeploymentScanner.java:265)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
>         at org.jboss.Main.boot(Main.java:187)
>         at org.jboss.Main$1.run(Main.java:438)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:201)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
> ossPolicyConfiguration.java:160)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
>         ... 94 more
> Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
> tion: linkConfiguration from state:inService
>         at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:196)
>         ... 96 more
> 15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
> ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
> 15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 06:57:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 06:57:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27877580.1158231462924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little closed JBESB-112.
-----------------------------

    Resolution: Done

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 14 06:59:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 06:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-11) Error redeploying
	dependent war
Message-ID: <14401878.1158231584539.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-11?page=all ]

Dimitris Andreadis updated JBAS-11:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

Scott points out that compex dependencies like this is really to be solved in JBoss5, so I'm rescheduling.

> Error redeploying dependent war
> -------------------------------
>
>                 Key: JBAS-11
>                 URL: http://jira.jboss.com/jira/browse/JBAS-11
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.0.0 Final
>            Reporter: bern
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-5.0.0.CR1
>
>
> This is a taken from the forum post from octopus see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=56015.
> I have a deployed webapp which depends on some mbean (having depends  clause in jboss-web.xml).
> When mbean is being redeployed it causes redeploying this webapp which finishes with NPE in WebModule.java
> This bug reproduced in both jboss 4.0.0 and 3.2.6
> Simple test case:
> Create sample service in /deploy, for example test-properties-service.xml
> Code:
> <server>
>     <mbean code="org.jboss.varia.property.SystemPropertiesService"
>         name="test:service=SystemProperties">
>         <!-- Set propertuies using the properties file style. -->
>         <attribute name="Properties">
>          </attribute>
>     </mbean>
> </server>
> 	
> Create sample war which depends on this service, for example
> Code:
> test.war
>            |
>             WEB-INF
>                           |
>                            web.xml
>                             jboss-web.xml
>            |
>              META-INF
> 	
> where web.xml
> Code:
> <web-app >
> </web-app>
> 	
> jboss-web.xml
> Code:
> <jboss-web>
>     <depends>test:service=SystemProperties</depends>
> </jboss-web>
> 	
> now both test-properties-service.xml and test.war placed in /deploy and deployed successfully.
> Now update test-properties-service.xml (edit-save, touch, etc)
> jboss will try to redeploy test.war with following result:
> Code:
> 13:22:33,483 DEBUG [MainDeployer] Undeploying file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-pr
> operties-service
> .xml
> 13:22:33,483 DEBUG [SARDeployer] undeploying document file:/C:/Cluster/jboss-3.2.6/server/all/deploy
> /test-properties
> -service.xml
> 13:22:33,499 DEBUG [SARDeployer] stopping mbean test:service=SystemProperties
> 13:22:33,499 DEBUG [ServiceController] stopping service: test:service=SystemProperties
> 13:22:33,514 DEBUG [ServiceController] stopping dependent services for: test:service=SystemPropertie
> s depende
> nt services are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: RUNNING
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:33,530 DEBUG [ServiceController] stopping service: jboss.web.deployment:war=test.war,id=-10807
> 43623
> 13:22:33,530 DEBUG [ServiceController] stopping dependent services for: jboss.web.deployment:war=tes
> t.war,id=-1080743623
> dependent services are: []
> 13:22:33,546 DEBUG [WebModule] Stopping jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,546 INFO  [TomcatDeployer] undeploy, ctxPath=/test, warUrl=file:/C:/Cluster/jboss-3.2.6/ser
> ver/all/tmp/deploy/tm
> p45130test.war/
> 13:22:33,577 DEBUG [Context] Stopping
> 13:22:33,577 DEBUG [Context] Stopping filters
> 13:22:33,577 DEBUG [Context]  Stopping filter 'CommonHeadersFilter'
> 13:22:33,592 DEBUG [Context] Processing standard container shutdown
> 13:22:33,608 DEBUG [Context] Sending application stop events
> 13:22:33,624 DEBUG [Context] resetContext jboss.web:j2eeType=WebModule,name=//localhost/test,J2EEApp
> lication=none,J2EESer
> ver=none org.jboss.mx.server.MBeanServerImpl at f99ff5
> 13:22:33,624 DEBUG [Context] Stopping complete
> 13:22:33,639 DEBUG [WebModule] Stopped jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,639 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.stop,sequenceNumber=225,timeStamp=10993981536
> 39,message=null,userD
> ata=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:33,655 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.stop,sequenceNumber=226,timeStamp=10993981536
> 55,message=null,userD
> ata=test:service=SystemProperties]
> 13:22:33,671 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.stop,sequenceNumber=114,timeStamp=10993981536
> 71,message=null,userD
> ata=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/deplo
> y/test-propertie
> s-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: Deployed
>   state: STARTED
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099397960936
>   lastModified: 1099397960874
>   mbeans:
>     test:service=SystemProperties state: Stopped
> ]
> 13:22:33,717 DEBUG [SARDeployer] destroying mbean test:service=SystemProperties
> 13:22:33,717 DEBUG [ServiceController] destroying service: test:service=SystemProperties
> 13:22:33,717 DEBUG [ServiceController] destroying dependent services for: test:service=SystemPropert
> ies depen
> dent services are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: STOPPED
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:33,749 DEBUG [ServiceController] destroying service: jboss.web.deployment:war=test.war,id=-108
> 0743623
> 13:22:33,749 DEBUG [ServiceController] destroying dependent services for: jboss.web.deployment:war=t
> est.war,id=-108074362
> 3 dependent services are: []
> 13:22:33,764 DEBUG [ServiceController] stopping service: jboss.web.deployment:war=test.war,id=-10807
> 43623
> 13:22:33,764 DEBUG [WebModule] Destroying jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,764 DEBUG [WebModule] Destroyed jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,764 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=227,timeStamp=10993981
> 53764,message=null,us
> erData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:33,780 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=
> 227,timeStamp=1099398
> 153764,message=null,userData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:33,811 DEBUG [ServiceController] stopping service: test:service=SystemProperties
> 13:22:33,811 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=228,timeStamp=10993981
> 53811,message=null,us
> erData=test:service=SystemProperties]
> 13:22:33,827 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=
> 228,timeStamp=1099398
> 153811,message=null,userData=test:service=SystemProperties]
> 13:22:33,827 DEBUG [SARDeployer] removing mbean test:service=SystemProperties
> 13:22:33,842 DEBUG [ServiceController] removing service: test:service=SystemProperties
> 13:22:33,842 DEBUG [ServiceController] removing test:service=SystemProperties from server
> 13:22:33,842 DEBUG [ServiceController] Context not removed, it is recording dependencies: ObjectName
> : test:se
> rvice=SystemProperties
>  state: DESTROYED
>  I Depend On:
>  Depends On Me:  jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,874 DEBUG [SARDeployer] Unregistering service UCL=jmx.loading:UCL=17210a5
> 13:22:33,874 DEBUG [UnifiedLoaderRepository3] UnifiedLoaderRepository removed(false) org.jboss.mx.lo
> ading.UnifiedClassLoa
> der3 at 17210a5{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/tmp45117test-properties-service
> .xml ,addedOrder
> =21}
> 13:22:33,889 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.destroy,sequenceNumber=115,timeStamp=10993981
> 53889,message=null,us
> erData=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/de
> ploy/test-proper
> ties-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: Deployed
>   state: STARTED
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099397960936
>   lastModified: 1099397960874
>   mbeans:
>     test:service=SystemProperties (state not available)
> ]
> 13:22:33,936 DEBUG [J2EEManagedObject] removeObject(), name: test:service=SystemProperties, encrypte
> d name: d
> ukascopy.system%3aservice%3dSystemProperties, search criteria: jboss.management.local:j2eeType=MBean
> ,*,name=test.sys
> tem%3aservice%3dSystemProperties
> 13:22:33,952 DEBUG [MBean] preDeregister(), parent: jboss.management.local:J2EEServer=Local,j2eeType
> =ServiceModule,name=d
> ukascopy-properties-service.xml
> 13:22:33,967 DEBUG [ServiceModuleFactory] Destroy MBean, name: test:service=SystemProperties
> 13:22:33,967 DEBUG [ServiceModule] destroy(), remove Service Module: test-properties-service.xml
> 13:22:33,967 DEBUG [J2EEManagedObject] removeObject(), name: test-properties-service.xml, encrypted 
> name: test-
> properties-service.xml, search criteria: jboss.management.local:j2eeType=ServiceModule,*,name=test-p
> roperties-servic
> e.xml
> 13:22:33,983 DEBUG [ServiceModule] preDeregister(), parent: jboss.management.local:j2eeType=J2EEServ
> er,name=Local
> 13:22:33,983 DEBUG [ServiceModuleFactory] Removed JSR-77 SAR: test-properties-service.xml
> 13:22:33,999 DEBUG [UnifiedClassLoader] Unregistering ucl=org.jboss.mx.loading.UnifiedClassLoader3 at 1
> 7210a5{ url=file:/C:/
> Cluster/jboss-3.2.6/server/all/tmp/deploy/tmp45117test-properties-service.xml ,addedOrder=21}
> 13:22:33,999 DEBUG [UnifiedLoaderRepository3] UnifiedLoaderRepository removed(true) org.jboss.mx.loa
> ding.UnifiedClassLoad
> er3 at 17210a5{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/tmp45117test-properties-service.
> xml ,addedOrder=
> 21}
> 13:22:34,014 DEBUG [DeploymentInfo] Cleaned Deployment: file:/C:/Cluster/jboss-3.2.6/server/all/tmp/
> deploy/tmp45117dukasc
> opy-properties-service.xml
> 13:22:34,014 DEBUG [MainDeployer] Undeployed file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-pro
> perties-service.
> xml
> 13:22:34,030 DEBUG [MainDeployer] Starting deployment of package: file:/C:/Cluster/jboss-3.2.6/serve
> r/all/deploy/dukascop
> y-properties-service.xml
> 13:22:34,030 DEBUG [MainDeployer] Starting deployment (init step) of package at: file:/C:/Cluster/jb
> oss-3.2.6/server/all/
> deploy/test-properties-service.xml
> 13:22:34,046 DEBUG [MainDeployer] Copying file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-proper
> ties-service.xml
>  -> C:\Cluster\jboss-3.2.6\server\all\tmp\deploy\tmp45131test-properties-service.xml
> 13:22:34,061 DEBUG [MainDeployer] using deployer org.jboss.deployment.SARDeployer at 15a0305
> 13:22:34,077 DEBUG [SARDeployer] about to copy 0 local directories
> 13:22:34,077 DEBUG [SARDeployer] looking for nested deployments in : file:/C:/Cluster/jboss-3.2.6/se
> rver/all/deploy/dukas
> copy-properties-service.xml
> 13:22:34,092 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.init,sequenceNumber=116,timeStamp=10993981540
> 92,message=null,userD
> ata=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/deplo
> y/test-propertie
> s-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: null
>   state: INIT_DEPLOYER
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 0
>   lastModified: 0
>   mbeans:
> ]
> 13:22:34,139 DEBUG [DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repos
> itoryName: JMImplemen
> tation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null
> , repositoryConfig: n
> ull)
> 13:22:34,155 DEBUG [UnifiedClassLoader] New jmx UCL with url file:/C:/Cluster/jboss-3.2.6/server/all
> /tmp/deploy/tmp45131d
> ukascopy-properties-service.xml
> 13:22:34,155 DEBUG [UnifiedClassLoader] setRepository, r=org.jboss.mx.loading.UnifiedLoaderRepositor
> y3 at 1b8e059, ucl=org.j
> boss.mx.loading.UnifiedClassLoader3 at 37dde9{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/t
> mp45131test-prop
> erties-service.xml ,addedOrder=0}
> 13:22:34,171 DEBUG [UnifiedClassLoader] setRepository, r=org.jboss.mx.loading.UnifiedLoaderRepositor
> y3 at 1b8e059, ucl=org.j
> boss.mx.loading.UnifiedClassLoader3 at 37dde9{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/t
> mp45131test-prop
> erties-service.xml ,addedOrder=0}
> 13:22:34,186 DEBUG [UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 37dde9
> { url=file:/C:/Cluste
> r/jboss-3.2.6/server/all/tmp/deploy/tmp45131test-properties-service.xml ,addedOrder=0}
> 13:22:34,186 DEBUG [MainDeployer] found 0 subpackages of file:/C:/Cluster/jboss-3.2.6/server/all/dep
> loy/test-propert
> ies-service.xml
> 13:22:34,202 DEBUG [MainDeployer] Watching new file: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/
> test-properties-
> service.xml
> 13:22:34,202 DEBUG [MainDeployer] create step for deployment file:/C:/Cluster/jboss-3.2.6/server/all
> /deploy/test-pro
> perties-service.xml
> 13:22:34,217 DEBUG [SARDeployer] Deploying SAR, create step: url file:/C:/Cluster/jboss-3.2.6/server
> /all/deploy/test
> -properties-service.xml
> 13:22:34,217 DEBUG [SARDeployer] Registering service UCL=jmx.loading:UCL=37dde9
> 13:22:34,233 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:34,233 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=487 time=1099398154233 message=nul
> l objectName=jmx.load
> ing:UCL=37dde9 userData=null, handback:2147483647
> 13:22:34,264 DEBUG [ServiceCreator] About to create bean: test:service=SystemProperties with code: o
> rg.jboss.
> varia.property.SystemPropertiesService
> 13:22:34,280 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:34,280 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=488 time=1099398154280 message=nul
> l objectName=dukascop
> y.system:service=SystemProperties userData=null, handback:2147483647
> 13:22:34,296 DEBUG [ServiceCreator] Created bean: test:service=SystemProperties
> 13:22:34,296 DEBUG [ServiceConfigurator] Properties set to {test.mt.chart.chartserver.url=http://fre
> eserv.test.
> com/ru.test.server.auto.image/chart/, test.mt.datalayer.cache.url=rmi://192.168.100.174:1099/CacheSe
> rver} in du
> kascopy.system:service=SystemProperties
> 13:22:34,311 DEBUG [ServiceController] Creating service test:service=SystemProperties
> 13:22:34,311 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=229,timeStamp=109939815
> 4311,message=null,use
> rData=test:service=SystemProperties]
> 13:22:34,327 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=2
> 29,timeStamp=10993981
> 54311,message=null,userData=test:service=SystemProperties]
> 13:22:34,342 DEBUG [ServiceController] Creating dependent components for: test:service=SystemPropert
> ies depen
> dents are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: DESTROYED
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:34,374 DEBUG [ServiceController] Creating service jboss.web.deployment:war=test.war,id=-108074
> 3623
> 13:22:34,374 DEBUG [WebModule] Creating jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:34,389 DEBUG [WebModule] Created jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:34,405 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=230,timeStamp=109939815
> 4405,message=null,use
> rData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:34,421 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=2
> 30,timeStamp=10993981
> 54405,message=null,userData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:34,436 DEBUG [ServiceController] Creating dependent components for: jboss.web.deployment:war=t
> est.war,id=-108074362
> 3 dependents are: []
> 13:22:34,436 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.create,sequenceNumber=117,timeStamp=109939815
> 4436,message=null,use
> rData=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/dep
> loy/test-propert
> ies-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: null
>   state: CREATE_DEPLOYER
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099398154202
>   lastModified: 1099398154061
>   mbeans:
>     test:service=SystemProperties state: Created
> ]
> 13:22:34,483 DEBUG [MainDeployer] Done with create step of deploying test-properties-service.xml
> 13:22:34,499 DEBUG [MainDeployer] Begin deployment start file:/C:/Cluster/jboss-3.2.6/server/all/dep
> loy/test-propert
> ies-service.xml
> 13:22:34,499 DEBUG [SARDeployer] Deploying SAR, start step: url file:/C:/Cluster/jboss-3.2.6/server/
> all/deploy/test-
> properties-service.xml
> 13:22:34,514 DEBUG [ServiceController] starting service test:service=SystemProperties
> 13:22:34,514 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.start,sequenceNumber=231,timeStamp=1099398154
> 514,message=null,user
> Data=test:service=SystemProperties]
> 13:22:34,530 DEBUG [ServiceController] Starting dependent components for: test:service=SystemPropert
> ies depen
> dent components: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: CREATED
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:34,546 DEBUG [ServiceController] starting service jboss.web.deployment:war=test.war,id=-108074
> 3623
> 13:22:34,546 DEBUG [WebModule] Starting jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:34,561 ERROR [WebModule] Starting failed jboss.web.deployment:war=test.war,id=-1080743623
> java.lang.NullPointerException
>         at org.jboss.web.WebModule.startModule(WebModule.java:61)
>         at org.jboss.web.WebModule.startService(WebModule.java:40)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
>         at $Proxy18.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:414)
>         at org.jboss.system.ServiceController.start(ServiceController.java:436)
>         at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:251)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:829)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
>         at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy8.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:304)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:460)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeplo
> ymentScanner.java:201
> )
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploym
> entScanner.java:212)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeployme
> ntScanner.java:191)
> 13:22:34,717 WARN  [ServiceController] Problem starting service jboss.web.deployment:war=test.war,id
> =-1080743623
> RuntimeMBeanException: java.lang.NullPointerException
> Cause: java.lang.NullPointerException
>         at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.ja
> va:82)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
>         at $Proxy18.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:414)
>         at org.jboss.system.ServiceController.start(ServiceController.java:436)
>         at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:251)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:829)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
>         at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy8.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:304)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:460)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeplo
> ymentScanner.java:201
> )
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploym
> entScanner.java:212)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeployme
> ntScanner.java:191)
> Caused by: java.lang.NullPointerException
>         at org.jboss.web.WebModule.startModule(WebModule.java:61)
>         at org.jboss.web.WebModule.startService(WebModule.java:40)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         ... 40 more
> 13:22:34,921 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.start,sequenceNumber=118,timeStamp=1099398154
> 921,message=null,user
> Data=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/depl
> oy/test-properti
> es-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: Starting
>   state: START_DEPLOYER
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099398154202
>   lastModified: 1099398154061
>   mbeans:
>     test:service=SystemProperties state: Started
> ]
> 13:22:34,967 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:34,967 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=489 time=1099398154967 message=nul
> l objectName=jboss.ma
> nagement.local:J2EEServer=Local,j2eeType=ServiceModule,name=test-properties-service.xml userData=nul
> l, handback:2147
> 483647
> 13:22:34,983 DEBUG [ServiceModule] postRegister(), parent: jboss.management.local:j2eeType=J2EEServe
> r,name=Local
> 13:22:34,999 DEBUG [ServiceModule] Created JSR-77 ServiceModule, name: test-properties-service.xml
> 13:22:34,999 DEBUG [ServiceModuleFactory] Created ServiceModule: jboss.management.local:J2EEServer=L
> ocal,j2eeType=Service
> Module,name=test-properties-service.xml
> 13:22:35,014 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:35,014 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=490 time=1099398155014 message=nul
> l objectName=jboss.ma
> nagement.local:J2EEApplication=null,J2EEServer=Local,ServiceModule=test-properties-service.xml,j2eeT
> ype=MBean,name=d
> ukascopy.system%3aservice%3dSystemProperties userData=null, handback:2147483647
> 13:22:35,030 DEBUG [MBean] postRegister(), parent: jboss.management.local:J2EEServer=Local,j2eeType=
> ServiceModule,name=du
> kascopy-properties-service.xml
> 13:22:35,046 DEBUG [ServiceModuleFactory] Create MBean, name: test:service=SystemProperties, SAR Mod
> ule: jbos
> s.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=test-properties-service.xml
> 13:22:35,046 DEBUG [MainDeployer] End deployment start on package: test-properties-service.xml
> 13:22:35,046 DEBUG [MainDeployer] Deployed package: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/t
> est-properties-s
> ervice.xml

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 07:03:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 07:03:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1490) EJB component
 environment (ENC) is not read only
Message-ID: <26812679.1158231818602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1490?page=all ]

Dimitris Andreadis updated JBAS-1490:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> EJB component environment (ENC) is not read only
> ------------------------------------------------
>
>                 Key: JBAS-1490
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1490
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-3.2.6 Final
>         Environment: Windows XP
>            Reporter: Tim Fox
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The component JNDI environment for a Stateless session bean does not appear to be read-only.
> I have a SLSB running in 3.2.6.
> It attempts to modify it's ENC (java:comp/env environment) and succeeds. I.e. the following succeeds:
> InitialContext ic = new InitialContext();
> Context envCtx = (Context)new InitialContext().lookup("java:comp/env");
> envCtx.bind("foo", "bar");
> log.debug("Worked!!");
> Also bind stuff into the context works.
> I haven't tried with other types of EJB.
> According to the EJB 2.0 spec (Sec. 20.2.4) an enterprise beans's environment should be read-only.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 07:03:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 07:03:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3614) failing
 org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
In-Reply-To: <5797013.1157137545169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2291995.1158231818746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3614?page=all ]

Dimitris Andreadis reassigned JBAS-3614:
----------------------------------------

    Assignee: Dimitris Andreadis  (was: Scott M Stark)

> failing org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3614
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3614
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> testRMMResourceImplementsMBean Failure
> testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> junit.framework.AssertionFailedError: testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> 	at org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase.testRMMResourceImplementsMBean(ModelMBeanTestCase.java:150)
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 07:19:37 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 07:19:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-137) Race condition in
	GPListener
Message-ID: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>

Race condition in GPListener
----------------------------

                 Key: JBESB-137
                 URL: http://jira.jboss.com/jira/browse/JBESB-137
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Esteban Schifman
             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 14 07:19:37 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 07:19:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10259769.1158232777684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little closed JBESB-137.
-----------------------------

    Resolution: Done

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 14 08:27:37 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Thu, 14 Sep 2006 08:27:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10727563.1158236857260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=all ]

Roland R?z reopened EJBTHREE-679:
---------------------------------

             
http://jira.jboss.com/jira/browse/JBINSTALL-42


I think that the Properties Service is not sufficient to provide a different naming convention. What I thought about was a way  to plug in a different default naming convention.

The interface could look like this:

public interface DefaultJndiNameProvider {
	String getDefaultRemoteJndiName(Container container);
	String getDefaultLocalJndiName(Container container);
}

Currently the org.jboss.ejb3.ProxyFactoryHelper uses the  [<earname>/]<ejbname>/[remote|local] naming convention. We use a different naming convention to support multiple jboss instances which can use each other. With a default jndi name provider we could get rid of the "pain" from configuring the jndi name for each bean.

The implementation of the DefaultJndiNameProvider could be configured using a System Property.


> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 08:55:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 08:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1114078.1158238534998.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3600?page=all ]

Dimitris Andreadis closed JBAS-3600.
------------------------------------

       Resolution: Done
         Assignee: Dimitris Andreadis
    Fix Version/s: JBossAS-5.0.0.Beta

Fixed the order of tests

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Thu Sep 14 09:05:41 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 14 Sep 2006 09:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7846137.1158239141333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Thomas Diesler updated JBAS-3626:
---------------------------------

    Summary: Upgrade jbossws to 1.1.0.GA  (was: Upgrade jbossws to 1.0.4.GA)

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.GA
>
>
> Upgrade to jbossws-1.0.4.GA, when it becomes available

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:05:41 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 14 Sep 2006 09:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30555812.1158239141497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Thomas Diesler updated JBAS-3626:
---------------------------------

    Description:     (was: Upgrade to jbossws-1.0.4.GA, when it becomes available)

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 14 09:05:41 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 14 Sep 2006 09:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18908320.1158239141667.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3626?page=comments#action_12343317 ] 
            
Thomas Diesler commented on JBAS-3626:
--------------------------------------

Release date is 31-Oct-2006

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 14 09:27:38 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 14 Sep 2006 09:27:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3655) Reduce logging for
 the construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7494852.1158240458133.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3655?page=comments#action_12343318 ] 
            
Anil Saldhana commented on JBAS-3655:
-------------------------------------

As long as there is no lengthy exception, I am fine. I do not think there is a necessity for every interceptor to have an injection of MBeanInvoker.

Please close the issue. I am not adding the ctrs to AuthxxxInterceptors.

> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:31:35 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Thu, 14 Sep 2006 09:31:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-136) Define a set of
 EPRs for Email, Ftp and Database.
In-Reply-To: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12863353.1158240695984.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-136?page=comments#action_12343319 ] 
            
Arvinder Singh commented on JBESB-136:
--------------------------------------

Added basic email-epr/email xsd skeleton under workspace/rearchitecture. More progress to follow

> Define a set of EPRs for Email, Ftp and Database.
> -------------------------------------------------
>
>                 Key: JBESB-136
>                 URL: http://jira.jboss.com/jira/browse/JBESB-136
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Arvinder Singh
>         Assigned To: Arvinder Singh
>             Fix For: 4.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:45:49 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 09:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16040187.1158241549937.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Dimitris Andreadis updated JBAS-3626:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
                   JBossAS-4.0.6.CR1

The 4.0.5.GA release will come earlier, so rescheduling the upgrade for 4.0.6.CR1.

If jbossws-1.1.0 could be used as a drop-in replacement for 1.0.3 that would by handy.

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:45:50 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 09:45:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26559099.1158241550135.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Dimitris Andreadis updated JBAS-3626:
-------------------------------------

    Affects Version/s:     (was: JBossAS-4.0.5.CR1)

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:49:52 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 09:49:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3655) Reduce logging for the
 construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30935255.1158241792457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis closed JBAS-3655.
------------------------------------

      Assignee: Dimitris Andreadis  (was: Anil Saldhana)
    Resolution: Done

The lengthy exception is gone.

> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:54:47 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 09:54:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-257) Test extender test
 in a scoped environment
Message-ID: <1921954.1158242087259.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-257?page=comments#action_12343322 ] 
            
Kabir Khan commented on JBAOP-257:
----------------------------------

Construtors done

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:29:48 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Thu, 14 Sep 2006 10:29:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1004) Jboss Portal to
 support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22320242.1158244188149.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ]

Sverker Abrahamsson updated JBPORTAL-1004:
------------------------------------------

    Attachment: jboss-portal-2.4-2.patch

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4-2.patch, jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:33:47 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Thu, 14 Sep 2006 10:33:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30461399.1158244427740.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343323 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

I have uploaded a new patch which binds virtual hosts to the portal instead of context.


> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4-2.patch, jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:53:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:53:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-119) Parameter loading
 doesn't check for XML validity
In-Reply-To: <7780536.1154950212823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21450027.1158245627544.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-119?page=all ]

Mark Little reassigned JBESB-119:
---------------------------------

    Assignee: Esteban Schifman  (was: Mark Little)

> Parameter loading doesn't check for XML validity
> ------------------------------------------------
>
>                 Key: JBESB-119
>                 URL: http://jira.jboss.com/jira/browse/JBESB-119
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>            Priority: Critical
>             Fix For: 4.0
>
>
> The current ParamRepository approach has a File implementation. It all appears to work on Strings (with the comments indicating how the strings should be formatted for structured attributes). However, some user classes assume the String is XML. Parameters should be provided to application classes through name/value pairs. How those pairs are loaded into the system (XML, strings, file, etc.) should be hidden.
> We also need an ESB schema.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:55:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:55:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-122) Schema needed
In-Reply-To: <17213696.1154955972421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13232847.1158245747498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-122?page=all ]

Mark Little reassigned JBESB-122:
---------------------------------

    Assignee: Esteban Schifman  (was: Mark Little)

> Schema needed
> -------------
>
>                 Key: JBESB-122
>                 URL: http://jira.jboss.com/jira/browse/JBESB-122
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>            Priority: Critical
>             Fix For: 4.0
>
>
> XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-120) ObjectStore
 configured differently from other components
In-Reply-To: <8533363.1154951052094.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32239071.1158245867604.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-120?page=all ]

Mark Little reassigned JBESB-120:
---------------------------------

    Assignee: Daniel Brum  (was: Kurt Stam)

> ObjectStore configured differently from other components
> --------------------------------------------------------
>
>                 Key: JBESB-120
>                 URL: http://jira.jboss.com/jira/browse/JBESB-120
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0
>
>
> Why does the object store configuration work differently from other components? Specifically, it doesn't use the ParamsRepository approach.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-48) I18N/L10N compliance
Message-ID: <15136899.1158245867781.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-48?page=all ]

Mark Little updated JBESB-48:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> I18N/L10N compliance
> --------------------
>
>                 Key: JBESB-48
>                 URL: http://jira.jboss.com/jira/browse/JBESB-48
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Optional
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:59:48 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:59:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-70) Create separate
	Nagios plugin
Message-ID: <9200412.1158245988069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-70?page=all ]

Mark Little updated JBESB-70:
-----------------------------

    Fix Version/s:     (was: 4.0)
                   4.1

> Create separate Nagios plugin
> -----------------------------
>
>                 Key: JBESB-70
>                 URL: http://jira.jboss.com/jira/browse/JBESB-70
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Johan Kumps
>             Fix For: 4.1
>
>
> - common\src\org\jboss\soa\esb\util\NagiosStandaloneHeartbeat.java
> 1) Refactor into a nagios specific plugin package? 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:59:48 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:59:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-117) Variable names should
 be more readable
In-Reply-To: <19656339.1154939172165.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9558634.1158245988215.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-117?page=all ]

Mark Little closed JBESB-117.
-----------------------------

    Resolution: Done

This should be fixed as part of the move to a coding convention.

> Variable names should be more readable
> --------------------------------------
>
>                 Key: JBESB-117
>                 URL: http://jira.jboss.com/jira/browse/JBESB-117
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> Some variables in the code are shortened and difficult to read.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:01:48 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:01:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18408709.1158246108490.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little updated JBESB-118:
------------------------------

    Fix Version/s:     (was: 4.0)
                   4.1

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-44) Transaction bridging
Message-ID: <16451736.1158249467568.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-44?page=all ]

Mark Little updated JBTM-44:
----------------------------

    Fix Version/s:     (was: 4.4)
                   4.6

> Transaction bridging
> --------------------
>
>                 Key: JBTM-44
>                 URL: http://jira.jboss.com/jira/browse/JBTM-44
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation, WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.6
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-50) Open source WS-Context
 implementation
Message-ID: <30076197.1158249467704.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-50?page=all ]

Mark Little updated JBTM-50:
----------------------------

    Fix Version/s:     (was: 4.4)
                   4.6

> Open source WS-Context implementation
> -------------------------------------
>
>                 Key: JBTM-50
>                 URL: http://jira.jboss.com/jira/browse/JBTM-50
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.6
>
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-123) Integrate with AS 5.0
Message-ID: <31369972.1158249467860.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate with AS 5.0
---------------------

                 Key: JBTM-123
                 URL: http://jira.jboss.com/jira/browse/JBTM-123
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Jonathan Halliday
             Fix For: 4.4




-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:02:39 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 12:02:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-20) Ensure ATS logging
 capabilities are compatible with JBoss
Message-ID: <6757195.1158249759200.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-20?page=all ]

Mark Little reassigned JBTM-20:
-------------------------------

    Assignee: Jonathan Halliday  (was: Kevin Conner)

> Ensure ATS logging capabilities are compatible with JBoss
> ---------------------------------------------------------
>
>                 Key: JBTM-20
>                 URL: http://jira.jboss.com/jira/browse/JBTM-20
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>            Priority: Minor
>             Fix For: 4.4
>
>
> ATS has its own way of logging errors, warnings, debugging etc. Although it follows JDK 1.4 logging specification (and can use log4j as an implementation), we need to ensure it is compatible with the standard way of logging in the result of JBoss.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:02:39 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 12:02:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4304387.1158249759362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-98?page=all ]

Mark Little reassigned JBTM-98:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:02:39 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 12:02:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-92) Print error message
 when prepare fails in XAResource
Message-ID: <31701589.1158249759521.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-92?page=all ]

Mark Little reassigned JBTM-92:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> 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: Jonathan Halliday
>            Priority: Minor
>             Fix For: 4.4
>
>
> 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

        


From jira-events at jboss.com  Thu Sep 14 12:30:35 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-257) Test extender test in
 a scoped environment
Message-ID: <18885220.1158251435507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-257?page=all ]

Kabir Khan closed JBAOP-257.
----------------------------

    Resolution: Done

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:40:36 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-285) overloaded method
 super calls do not get intercepted with generated advisors
Message-ID: <19742940.1158252037003.JavaMail.jira@cloud.prod.atl2.jboss.com>

overloaded method super calls do not get intercepted with generated advisors
----------------------------------------------------------------------------

                 Key: JBAOP-285
                 URL: http://jira.jboss.com/jira/browse/JBAOP-285
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.0.0.alpha


class Base{
   void superCall(){}
}

class Sub extends Base{
   void superCall(){super.superCall();}
}

<bind pointcut="execution(* $instanceof{Base}->superCall())">
   <interceptor class="X"/>
</bind>

Sub sub = new Sub();
sub.superCall();

We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. 

I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:48:39 2006
From: jira-events at jboss.com (Jason Lenhart (JIRA))
Date: Thu, 14 Sep 2006 12:48:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-129) Wrong jar referred
 to in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11038848.1158252519303.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Jason Lenhart updated JBESB-129:
--------------------------------

    Complexity: Low

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:57:47 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <1077004.1158253067602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment: jboss-aop.jar

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:57:47 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <29689996.1158253067797.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment:     (was: jboss-aop.jar)

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:04:41 2006
From: jira-events at jboss.com (Marcos Tengelmann (JIRA))
Date: Thu, 14 Sep 2006 13:04:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-495) Allows for
 automatic meta data
 gathering during rule/rule package saves to repository
Message-ID: <32823093.1158253481712.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allows for automatic meta data gathering during rule/rule package saves to repository
-------------------------------------------------------------------------------------

                 Key: JBRULES-495
                 URL: http://jira.jboss.com/jira/browse/JBRULES-495
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-brms
            Reporter: Marcos Tengelmann
         Assigned To: Mark Proctor
            Priority: Optional


In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.

The whole idea here is to keep the concept of Category only for business purposes.

Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions

With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:17:36 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 14 Sep 2006 13:17:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9060183.1158254256682.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=all ]

Julien Viet resolved JBPORTAL-1036.
-----------------------------------

    Resolution: Done

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:37:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:37:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3126) Add tests for
 org.jboss.varia.scheduler facility
Message-ID: <13944163.1158255457188.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3126?page=all ]

Dimitris Andreadis updated JBAS-3126:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
                   JBossAS-4.0.6.CR1

> Add tests for org.jboss.varia.scheduler facility
> ------------------------------------------------
>
>                 Key: JBAS-3126
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3126
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We have zero tests for the scheduler stuff, so add this task as a reminder.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:43:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:43:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3658) Remote classloading
 service - Redesign
Message-ID: <2583525.1158255817852.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remote classloading service - Redesign
--------------------------------------

                 Key: JBAS-3658
                 URL: http://jira.jboss.com/jira/browse/JBAS-3658
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Remoting
            Reporter: Dimitris Andreadis
         Assigned To: Tom  Elrod
             Fix For: JBossAS-4.0.6.CR1


We need to redesign the remote classloading service such that there is more control at the deployment layer on what is exposed.

I will create a forum thread where this can be discussed in more detail.

Requirement 1:
Provide sensible defaults, which probably means no remote classloading by default

Requirement 2:
Individual deployments can choose whether remote classloading is enabled and what is available remotely

Requirement 3:
Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or AOP remoting proxies

Requirement 4:
Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable

Requirement 5:
Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that triggers the use of invokers to do remote classloading.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:45:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:45:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2075) Remote classloading
 service - Redesign
Message-ID: <13862711.1158255939387.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2075?page=all ]

Dimitris Andreadis closed JBAS-2075.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Duplicate Issue

Re-opened this subtask as a feature request for the next release.

> Remote classloading service - Redesign
> --------------------------------------
>
>                 Key: JBAS-2075
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2075
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions:  JBossAS-4.0.3RC1
>            Reporter: Adrian Brock
>
> We need to redesign the remote classloading service such that there is more control at the deployment layer
> on what is exposed.
> I will create a forum thread where this can be discussed in more detail.
> Requirement 1:
> Provide sensible defaults, which probably means no remote classloading by default
> Requirement 2:
> Individual deployments can choose whether remote classloading is enabled and what is available remotely
> Requirement 3:
> Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or
> AOP remoting proxies
> Requirement 4:
> Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable
> Requirement 5:
> Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that
> triggers the use of invokers to do remote classloading.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:47:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:47:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2057) Need an EJB3 mbean
	JSR-77 mapping
Message-ID: <12833881.1158256057598.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2057?page=all ]

Dimitris Andreadis updated JBAS-2057:
-------------------------------------

     Issue Type: Feature Request  (was: Task)
    Component/s: EJB3
                 Management services
                     (was: EJB2)

> Need an EJB3 mbean JSR-77 mapping
> ---------------------------------
>
>                 Key: JBAS-2057
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2057
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just work.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:47:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:47:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2057) Need an EJB3 mbean
 JSR-77 mapping
Message-ID: <3351149.1158256057795.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2057?page=comments#action_12343332 ] 
            
Dimitris Andreadis commented on JBAS-2057:
------------------------------------------

I don't think we have free cycles for this now.

> Need an EJB3 mbean JSR-77 mapping
> ---------------------------------
>
>                 Key: JBAS-2057
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2057
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just work.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:59:38 2006
From: jira-events at jboss.com (Fabrice Daugan (JIRA))
Date: Thu, 14 Sep 2006 13:59:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-346) This project
 cannot be deployed to a server.
In-Reply-To: <24697603.1154610791446.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6361530.1158256778830.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-346?page=comments#action_12343333 ] 
            
Fabrice Daugan commented on JBIDE-346:
--------------------------------------

Exactly the same for :
- Windows XP Pro SP 2
- Java 1.5.0_07
- JBossAS 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)
- JBoss IDE 2.0.0 beta 1
- J2EE 1.3 and 1.4

> This project cannot be deployed to a server.
> --------------------------------------------
>
>                 Key: JBIDE-346
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-346
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossIDE Core
>    Affects Versions: 2.0.0.Alpha1a
>         Environment: - Windoze XP Pro SP 2
> - Java 1.5.0_07
> - JBossAS 4.0.4 GA patch 1
> - JBoss IDE 2.0.0 alpha 1a
>            Reporter: Michael Vilot
>         Assigned To: Marshall Culpepper
>
> After creating a J2EE 1.4 project and running XDoclet to generate the needed descriptors, unable to deploy.
> For Project -> Properties -> Server, dialog box says "This project cannot be deployed to a server."
> For Run -> Debug (?!?!) -> no JBoss server configuration appears.
> However, for New -> Server, a JBoss 4 server option appears, can be configured, and can be run/stopped from Eclipse. Unfortunately, the J2EE part of JBoss IDE does not recognize it at all.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:59:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:59:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2477) Exception in
 web-console j2ee domain after undeploy of application
Message-ID: <32489885.1158256779433.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2477?page=all ]

Dimitris Andreadis updated JBAS-2477:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Exception in web-console j2ee domain after undeploy of application
> ------------------------------------------------------------------
>
>                 Key: JBAS-2477
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2477
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Both Linux and Windows
>            Reporter: Lennart Petersson
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Had listed all apps in web-console j2ee domains. Then undeployed one app. Then list again in web-console ---> exception below.
> 10:31:54,896 INFO  [TomcatDeployer] undeploy, ctxPath=/crimeportal, warUrl=.../tmp/deploy/tmp65013crimeportal.war/
> 10:31:54,914 INFO  [EJBDeployer] Undeploying: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/CrimePortalBeans.jar
> 10:31:55,162 INFO  [ProxyFactory] Unbind EJB Home 'SicilianLaundry' from jndi 'SicilianLaundry'
> 10:31:55,172 INFO  [EjbModule] Undeployed SicilianLaundry
> 10:31:55,173 INFO  [ProxyFactory] Unbind EJB Home 'ShanghaiLaundry' from jndi 'ShanghaiLaundry'
> 10:31:55,173 INFO  [EjbModule] Undeployed ShanghaiLaundry
> 10:31:55,190 INFO  [EARDeployer] Undeploying J2EE application, destroy step: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/
> 10:32:01,401 INFO  [STDOUT] javax.management.InstanceNotFoundException: jboss.management.local:J2EEApplication=CrimePortal.ear,J2EEServer=Local,j2eeType=EJBModule,name=CrimePortalBeans.jar is not registered.
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:651)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDeployedObjects(JSR77Lister.java:167)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServer(JSR77Lister.java:194)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServers(JSR77Lister.java:218)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomain(JSR77Lister.java:233)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomains(JSR77Lister.java:256)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.getTreeForResource(JSR77Lister.java:282)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.helpers.AbstractPluginWrapper.getSubTreeForResource(AbstractPluginWrapper.java:201)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreesForResource(PluginManager.java:392)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreeForProfile(PluginManager.java:192)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:32:01,411 INFO  [STDOUT]     at java.lang.reflect.Method.invoke(Method.java:324)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.processRequest(InvokerServlet.java:90)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.doPost(InvokerServlet.java:133)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 10:32:01,430 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:534)
> 1

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 14:09:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 14:09:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3346)
 org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase
 causes 1.5 BEA JVM to core dump
Message-ID: <26782177.1158257377470.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3346?page=comments#action_12343334 ] 
            
Dimitris Andreadis commented on JBAS-3346:
------------------------------------------

We have been running the jboss testsuite on Branch_4_0 using bea jdk 1.5 for some time without any JVM core dumps.

http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite-1.5

Java Version 1.5.0_06 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


> org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase causes 1.5 BEA JVM to core dump
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3346
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: RHEL 4, x86_64 processor, BEA 1,5 JDK
>            Reporter: Len DiMaggio
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> With this JDK:
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> BEA JRockit(R) (build dra-45238-20050523-2021-linux-x86_64, R25.2.0-28)
> And this test from the JBoss 4.0.4/GA test suite (download from jboss.com) - the test causes a code dump when it executes line 62.
>      1	/*
>      2	* JBoss, Home of Professional Open Source
>      3	* Copyright 2005, JBoss Inc., and individual contributors as indicated
>      4	* by the @authors tag. See the copyright.txt in the distribution for a
>      5	* full listing of individual contributors.
>      6	*
>      7	* This is free software; you can redistribute it and/or modify it
>      8	* under the terms of the GNU Lesser General Public License as
>      9	* published by the Free Software Foundation; either version 2.1 of
>     10	* the License, or (at your option) any later version.
>     11	*
>     12	* This software is distributed in the hope that it will be useful,
>     13	* but WITHOUT ANY WARRANTY; without even the implied warranty of
>     14	* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>     15	* Lesser General Public License for more details.
>     16	*
>     17	* You should have received a copy of the GNU Lesser General Public
>     18	* License along with this software; if not, write to the Free
>     19	* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>     20	* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>     21	*/
>     22	package org.jboss.test.cmp2.batchcascadedelete.test;
>     23	
>     24	import org.jboss.test.JBossTestCase;
>     25	import org.jboss.test.cmp2.batchcascadedelete.ejb.Child;
>     26	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildHome;
>     27	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildUtil;
>     28	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildHome;
>     29	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildUtil;
>     30	import org.jboss.test.cmp2.batchcascadedelete.ejb.Parent;
>     31	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentHome;
>     32	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentUtil;
>     33	import junit.framework.Test;
>     34	
>     35	/**
>     36	 * @author <a href="mailto:alex at jboss.org">Alexey Loubyansky</a>
>     37	 * @version <tt>$Revision: 1.1.2.2 $</tt>
>     38	 */
>     39	public class BatchCascadeDeleteUnitTestCase
>     40	   extends JBossTestCase
>     41	{
>     42	   /**
>     43	    * Constructor for the JBossTestCase object
>     44	    *
>     45	    * @param name Test case name
>     46	    */
>     47	   public BatchCascadeDeleteUnitTestCase(String name)
>     48	   {
>     49	      super(name);
>     50	   }
>     51	
>     52	   public static Test suite() throws Exception
>     53	   {
>     54	      return JBossTestCase.getDeploySetup(BatchCascadeDeleteUnitTestCase.class, "cmp2-batchcascadedelete.jar");
>     55	   }
>     56	
>     57	   public void testCase4540() throws Exception
>     58	   {
>     59	      ParentHome parentHome = ParentUtil.getHome();
>     60	      Parent parent = parentHome.create("parent");
>     61	
>     62	      ChildHome childHome = ChildUtil.getHome();
>     63	      Child child = childHome.create( parent, "child");
>     64	
>     65	      GrandchildHome grandchildHome = GrandchildUtil.getHome();
>     66	
>     67	      // If you comment out the next line, then the call to child.remove() works fine.
>     68	      grandchildHome.create(child.getId(), "grandchild");
>     69	
>     70	      this is the test for non-null foreign key
>     71	      child.remove();
>     72	   }
>     73	}
> Here's the dump file:
> Linux x86_64-4as.lab.boston.redhat.com 2.6.9-39.ELsmp #1 SMP Thu Jun 1 18:01:55 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> ===== BEGIN DUMP =============================================================
> JRockit dump produced after 0 days, 00:29:38 on Wed Jun 21 13:56:36 2006
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Error Message: Illegal memory access. [54]
> Signal info  : si_signo=12, si_code=-6
> Version      : BEA JRockit(R) R25.2.0-28 dra-45238-20050523-2021-linux-x86_64
> GC           : System optimized over throughput (initial strategy singleparpar)
>              : GC strategy for GC 4 was genparpar
>              : GC strategy for GC 5 was singleparpar
>              : GC strategy for GC 6 was genparpar
>              : GC strategy for GC 7 was singleparpar
>              : GC strategy for GC 8 was genparpar
>              : mmHeap->data = 0x20000000, mmHeap->top = 0x28000000
>              : mmStartCompaction = 0x21800000, mmEndCompaction = 0x22000000
> CPU          : Intel Pentium 4 SSE SSE2 NetBurst EM64T
> Number CPUs  : 2
> Tot Phys Mem : 4120244224
> OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 4 Beta)
> Linux version 2.6.9-39.ELsmp (bhcompile at hs20-bc1-6.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Thu Jun 1 18:01:55 EDT 2006
> State        : JVM is running (Main thread has finished)
> Command Line : -Djrockit.launcher.type=jrockit.shipment -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/lib/endorsed org.jboss.Main -c all
> Environment  : JAVA_HOME=(null), java.home=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre, java.class.path=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar, java.library.path=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/../lib/amd64
> C Heap       : Good; no memory allocations have failed
> Registers (from context struct at 0x40e899f8/0x40e89a70):
> RAX = ffffffff00000010  RBX = 00000000f7bc5de8
> RCX = 00000000f7bc5df8  RDX = 00000000ffcb1bf3
> R8  = 000000000002feeb  R9  = 000000009090feeb
> R10 = 0000002a9b7aeed0  R11 = 0000002a9577893c
> R12 = 0000000040e89e58  R13 = 0000000000000001
> R14 = 0000000000000001  R15 = 0000002a9b7aed08
> RSI = 0000000020c8bb78  RDI = 00000000220b1108
> RSP = 0000000040e89eb0  RIP = 00000001009ccec8
> RBP = 00000000220b1108  RFL = 00000206
> CS = 0000 GS = 0000 FS = 0000
> Stack:
> 0000000040e89eb0: 0000000021ff0238 00000001009ccbb5 00000000220d6b28 0000000020c81130 0000000022078920 0000000021ff0238 
> 0000000040e89ee0: 0000000100000a22 0000000003c3d730 00000000220d6b40 0000000020c8bb48 0000000022078920 0000000021ff0238 
> 0000000040e89f10: 00000001009ca128 00000001009c9fdf 0000000022078920 0000000020c70cb0 00000000220b22a8 00000000220924a8 
> 0000000040e89f40: 0000000020c8bb48 0000000021ff0238 0000000022078920 0000000020c6ed78 00000001009c9c23 0000000020c6ee40 
> 0000000040e89f70: 0000000100000a45 000000000000001c 0000000021ff0238 0000000020c6ed78 0000000022078920 0000000021ff0238 
> 0000000040e89fa0: 00000001009c9b55 0000000020c137d8 00000001009c8e0f 0000000000000000 0000000022078920 0000000020b0b3b8 
> 0000000040e89fd0: 0000000021ff0238 0000000020c8b568 0000000000000000 0000000021ff0238 0000000020c137d8 0000000021ff0238 
> 0000000040e8a000: 0000000021ff0238 00000001009c8cb5 0000000020c0f3d8 00000001009c8bd4 0000000020c10a90 0000000003c064b0 
> 0000000040e8a030: 0000000021ff0238 0000000020c0f3d8 00000001009c8a8f 0000000003c057f0 0000000020a5ddb0 00000000220924a8 
> 0000000040e8a060: 00000001009c8296 0000000000000001 0000002a9b7aed08 000000010000090f 00000000005d7cd0 0000002a9b7aeed0 
> 0000000040e8a090: 00000000a6bf41f8 0000000020c0dca8 0000000021ff0238 0000000000000000 0000000020a5ddb0 0000000003bffb80 
> 0000000040e8a0c0: 0000000021ff0238 0000000000000000 0000000020a5ddb0 00000000220924a8 00000001009c7386 0000000020a5ddb0 
> 0000000040e8a0f0: 03c028209b7aed08 0000002a9b7aeed8 0000000020c0dca8 0000000000000000 00000000220924a8 0000000021ff0238 
> 0000000040e8a120: 0000000000000000 00000000220924a8 000000000000012c 0000002a9b7aeed0 0000000100000000 000000010002bdf0 
> 0000000040e8a150: 0000000020c08a38 0000000020a5ddb0 0000000100000a22 0000000003c00cf8 0000000000000001 00000000274b8c38 
> 0000000040e8a180: 0000000020c08a38 0000000021ff0238 00000001009c6da7 0000000100000a45 0000000020c0dca8 0000000021ff0238 
> 0000000040e8a1b0: 0000000000000000 0000000000000000 0000000021ff0238 00000001009c62a0 0000000021ff0238 0000000020c07368 
> 0000000040e8a1e0: 00000001009c612a 00000000005d7c90 0000000020c07368 0000000021ff0238 0000000021103b10 0000000000000000 
> 0000000040e8a210: 0000000021ff0238 0000000100000a45 000000000000001c 0000002a969f1010 0000000003bf6978 0000000020c05d48 
> 0000000040e8a240: 0000000021ff0238 00000001009c5b5f 0000000021ff0238 0000000000000000 0000000021ff4240 0000000020c05d48 
> 0000000040e8a270: 0000000021ff0238 0000000020b0b3b8 0000000021ff0238 00000001009c58b4 00000000210fb030 0000000040e8a3e0 
> 0000000040e8a2a0: 0000000020a5ddb0 00000001009c4f23 00000000269f9f90 0000000020b0b3b8 0000000021ff0238 0000000021033388 
> 0000000040e8a2d0: 0000010bf7bc5c80 00000000210fb030 0000002a00000001 0000000000000000 0000002a9b7aed08 0000002a956ad0b1 
> 0000000040e8a300: 000000000000029c 0000000002645f21 0000002a9b7aeec0 0000000040e8a598 0000000040e8a3e0 0000000040e8a560 
> 0000000040e8a330: 0000000100030068 0000000040e8a4f8 0000000040e8a3e0 00000001009c4b10 0000002a9b7aeb20 0000002a9b7aed08 
> 0000000040e8a360: 0000000000000001 0000000000000001 0000000040e8a3e0 0000002a9b7aed08 000000000064ca60 0000002a9560787a 
> 0000000040e8a390: 0000000000000002 0000002a956d3107 0000000103bb9370 000000000056aaa8 0000000040e8a500 0000002a9b7aee48 
> 0000000040e8a3c0: 0000002a9b7b3b00 0000002a956aca24 0000000003bb9370 0000000002643f80 0000002a9b7aee48 0000002a9b7aeec0 
> 0000000040e8a3f0: 0000000000000000 0000000100000000 0000000100000001 0000002a9b7aed28 0000000003bb9370 0000002a9b7aed08 
> 0000000040e8a420: 000000000056aaa8 0000000100000007 0000000200000001 0000000200000000 0000002a00000000 0000002a956c3228 
> 0000000040e8a450: 03bc261800000000 0000000002643f80 0000002a9b7aed08 0000002a9b7b3b00 0000002a9b7aee48 0000002a956c36f0 
> 0000000040e8a480: 0000000000000000 0000002a956c337c 0000002a956c36f0 0000000040e8a4f8 0000000040e8a500 0000000002643f80 
> 0000000040e8a4b0: 0000000000000001 0000002a9b7aee48 0000000000000000 0000002a9b7aed08 0000000002643f80 0000002a956c37c9 
> 0000000040e8a4e0: 011f3cc000000000 0000000040e8a4f8 000000010003af7a 0000002a9b7aeec8 0000000040e8a598 0000002a9b7aed08 
> 0000000040e8a510: 00000001001ecc8b 0000002a9b7aee58 0000002a9b7aeb20 0000000040e8a560 0000000000000001 0000000000000001 
> 0000000040e8a540: 0000002a9b7aed08 0000002a956cc14a 0000002a9b7aee48 000000010003c1e0 0000000000688b30 0000002a9b7aee48 
> 0000000040e8a570: 000000002192dec8 000000010003bfa7 0000000020b0b3b8 0000000021ff6d58 000000010003bea6 0000000021ff6be8 
> 0000000040e8a5a0: 0000000021ff6d58 0000000020b0b3b8 0000000021ff6be8 0000000100000001 0000000020b0b3b8 0000000020b0b3b8 
> 0000000040e8a5d0: 0000000021ff6be8 000000010005db3e 0000000021ff6be8 0000000021ff6d58 0000000020b0b3b8 0000000021ff6d98 
> 0000000040e8a600: 000000010003bd09 0000000021ff6be8 0000000021ff6be8 0000000021ff6be8 0000000020fa8d58 000000010003b2d5 
> 0000000040e8a630: 0000000021ff6be8 0000000020b0b3b8 0000000001939c68 0000000100003945 00000000200a1118 0000000025179958 
> 0000000040e8a660: 0000000000000001 000000000193de20 0000000021ff6c80 0000000020fa8d58 000000010023c5c8 0000000021ff6be8 
> 0000000040e8a690: 00000000ffffffff 0000000021ff6d10 0000000020ffd028 0000000021ff6c80 0000000020fa8d58 0000000020b0b3b8 
> Code:
> 00000001009ccdc8: 894890ff672533e8 c3d2f8252c8b48f3 0001025188b84803 ff6362c8e8000000 0e7ee82824748948 482824748b48ff67 
> 00000001009ccdf8: 00002a9b7ca2b8bf 26048b273c8b4800 7c8b48ff670fa3e8 0e16e826048b0824 0f0ee826048bff69 ee8948f78948ff67 
> 00000001009cce28: 90004d8b241c8948 50b848ff6bef21e8 9000000000010531 df8948ff63626be8 25048b4864f38948 28468948000000d8 
> 00000001009cce58: de8948ff647717e8 894890ff67249be8 ede81024748b48f3 85e8de8948ff6364 cccccccc90ff6724 8bfe8948f38948cf 
> 00000001009cce88: ffffffe0b848260c 480114ffffffffff 67b8c189c389de89 c1c889e9f7666666 89c2011fe8c104fa c82928c96bd189d8 
> 00000001009cceb8: 08768b48137fc085 1776084639d8f748 48c35b10c6748b48 127608463908768b 48c35b10c6748b48 000001009ccec6b8 
> 00000001009ccee8: 009cced6b848f400 ccccccf400000001 cccccccccccccccc 8b4840ec83485553 854820408b483846 4800000213840fc0 
> 00000001009ccf18: 4de838768b48f389 05e8f58948000002 8948c18948ff75bb 314830244c8948d8 44894838708b48db 0c8b20768b480824 
> 00000001009ccf48: e8ffff43e1e89026 24548b48ff63622c 89480824448b4830 244c8948ee8948f1 0093e910768b4828 8948304e8b480000 
> 00000001009ccf78: 8948d58948382474 8948cd2948302454 0c8b0824448948c6 48ffe4d635e89020 d53948d88948c289 480774c08548737c 
> 00000001009ccfa8: b84826eb38245c8b 00000000011df298 f38948ff6360f3e8 5c8948ff66b3dbe8 481024448b481024 48df894838245c8b 
> Loaded modules:
> (* denotes the module causing the exception)
> 0x400000-0x411037  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/bin/java
> 0x3a5dc00000-0x3a5dc0eff9  /lib64/tls/libpthread.so.0
> 0x3a5d400000-0x3a5d48459b  /lib64/tls/libm.so.6
> 0x3a5cf00000-0x3a5cf01c73  /lib64/libdl.so.2
> 0x3a5d100000-0x3a5d22ac59  /lib64/tls/libc.so.6
> 0x3a5cd00000-0x3a5cd1434f  /lib64/ld-linux-x86-64.so.2
> 0x2a95588000-0x2a957a660f  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit/libjvm.so
> 0x2a959e3000-0x2a959ecf13  /lib64/libnss_files.so.2
> 0x2a96c6f000-0x2a96c93473  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libjava.so
> 0x2a96d99000-0x2a96da5627  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libverify.so
> 0x3a62e00000-0x3a62e134eb  /lib64/libnsl.so.1
> 0x2a99d9f000-0x2a99db3fcf  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libnet.so
> 0x2a99eb6000-0x2a99ebed33  /lib64/libnss_nis.so.2
> 0x2a99fc0000-0x2a99fc38a3  /lib64/libnss_dns.so.2
> 0x3a5e200000-0x3a5e210d9b  /lib64/libresolv.so.2
> 0x2a9b5c8000-0x2a9b5c897b  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/librmi.so
> "RMI TCP Connection(4)-192.168.7" id=149 idx=0xc8 tid=1088993632 lastJavaFrame=(nil)
> Thread Stack Trace:
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Extended, platform specific info:
> libc release: 2.3.4-stable
> Elf headers:
> libc       ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5d11c4a0 PHOFF: 0x40 SHOFF: 0x13d5a8 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 69 STIDX: 66
> libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5dc05620 PHOFF: 0x40 SHOFF: 0x12980 EF: 0x0 HS: 64 PS: 56 PHN; 9 SS: 64 SHN: 38 STIDX: 35
> libjvm     ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x36c80 PHOFF: 0x40 SHOFF: 0x3106f0 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
> ===== END DUMP ===============================================================

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 14:11:39 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Thu, 14 Sep 2006 14:11:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-496) Sequential
 Accessor for the Action Language.
Message-ID: <10251090.1158257499132.JavaMail.jira@cloud.prod.atl2.jboss.com>

Sequential Accessor for the Action Language.
--------------------------------------------

                 Key: JBRULES-496
                 URL: http://jira.jboss.com/jira/browse/JBRULES-496
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1




-- 
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

        


From jira-events at jboss.com  Thu Sep 14 14:46:35 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 14:46:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-8) Port
 MarshalledValueIn(Out)putStream from aop
Message-ID: <14481718.1158259595983.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port MarshalledValueIn(Out)putStream from aop
---------------------------------------------

                 Key: JBCOMMON-8
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-8
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: core
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 2.0.0.Beta


A copy of AS/aop's MarshalledValueInputStream and MarshalledValueOutputStream should be added to common-core/org.jboss.util.stream.  These are prettyy straightforward extensions of the j2se ObjectStreams with only j2se dependencies.  Once a version of common with this in it is released, the other projects that use it can be converted.  Usages I'm aware of are:

AS via its version in the server module
AOP via its own version
JBoss Cache via dependency on the AS's jboss-minimal.jar

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 15:18:35 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 14 Sep 2006 15:18:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-88) Release 1.1 beta 2
Message-ID: <22904475.1158261515422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-88?page=all ]

Alejandro Guizar resolved BPEL-88.
----------------------------------

    Resolution: Done

Release posted to sourceforge and jboss labs:

http://labs.jboss.com/portal/jbossjbpm/downloads/bpel

> Release 1.1 beta 2
> ------------------
>
>                 Key: BPEL-88
>                 URL: http://jira.jboss.com/jira/browse/BPEL-88
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>
> The focus of this release is on time-driven activities: 
> a) <wait>
> b) <onAlarm> branches of <pick>
> c) <onAlarm> events in the <eventHandlers> section of scopes

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 15:22:38 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 15:22:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3656) Disconnect
 HAPartition channel upon failure in startService()
In-Reply-To: <12832750.1158180750351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28003950.1158261758406.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3656?page=all ]

Brian Stansberry updated JBAS-3656:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
         Priority: Critical  (was: Major)

> Disconnect HAPartition channel upon failure in startService()
> -------------------------------------------------------------
>
>                 Key: JBAS-3656
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3656
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> If an exception is thrown in ClusterPartition/HAPartition startService() after the channel is connected, the channel must be disconnected, or we've left a zombie member of the group.  Particularly in 4.0.x where the ServiceController will not undeploy a service that fails in start().
> Need to ensure stopService() properly handles a disconnected channel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 16:36:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 16:36:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3656) Disconnect
 HAPartition channel upon failure in startService()
In-Reply-To: <12832750.1158180750351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19576296.1158266194448.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3656?page=all ]

Brian Stansberry closed JBAS-3656.
----------------------------------

    Resolution: Done

> Disconnect HAPartition channel upon failure in startService()
> -------------------------------------------------------------
>
>                 Key: JBAS-3656
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3656
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
> If an exception is thrown in ClusterPartition/HAPartition startService() after the channel is connected, the channel must be disconnected, or we've left a zombie member of the group.  Particularly in 4.0.x where the ServiceController will not undeploy a service that fails in start().
> Need to ensure stopService() properly handles a disconnected channel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:16:37 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 17:16:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3587) Add a system
 property to configure TCPPING.initial_hosts
In-Reply-To: <19247726.1156955263825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25009990.1158268597757.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3587?page=all ]

Brian Stansberry updated JBAS-3587:
-----------------------------------

        Summary: Add a system property to configure TCPPING.initial_hosts  (was: Add a startup switch to configure TCPPING.initial_hosts)
    Description: 
We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:

<TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...

For now I'm going to go with just a system property.  If people want a startup switch they can request it.

  was:
As discussed on conf call, we want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a startup switch and system property to allow this to be externalized from the xml file, e.g:

<TCPPING initial_hosts={${jboss.tcp.initial.hosts:localhost[7800]} ...

Should discuss on the forum whether we want a startup switch or just a property set via -D.  My preference is a switch.


> Add a system property to configure TCPPING.initial_hosts
> --------------------------------------------------------
>
>                 Key: JBAS-3587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1, JBossAS-4.0.6.CR1
>
>
> We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:
> <TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...
> For now I'm going to go with just a system property.  If people want a startup switch they can request it.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:28:38 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Thu, 14 Sep 2006 17:28:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-599) remoting doc does
 not cover enabling or configuring leasing from the client side
Message-ID: <30643037.1158269318956.JavaMail.jira@cloud.prod.atl2.jboss.com>

remoting doc does not cover enabling or configuring leasing from the client side
--------------------------------------------------------------------------------

                 Key: JBREM-599
                 URL: http://jira.jboss.com/jira/browse/JBREM-599
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: docs
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
            Priority: Minor
             Fix For: 2.2.0.Beta1 (Bluto)




-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:32:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 14 Sep 2006 17:32:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-5) Integrate OpenDS
 in HEAD testsuite
In-Reply-To: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25958031.1158269554419.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/SECURITY-5?page=comments#action_12343341 ] 
            
Anil Saldhana commented on SECURITY-5:
--------------------------------------

I have been able to bootstrap the DS via a MBean Service and also shutdown properly (except for a glitch). There is a OpenDS JMXConnectionHandler lurking around listening on port 1689 after the shutdown.

https://opends.dev.java.net/issues/show_bug.cgi?id=648

This is no big deal. But takes away the ability to continuosly start/stop the DS cleanly as part of test setup.

Workaround:
Make the start/stop of the DS as part of the server configuration "start/stop" and let the tests deal with adding ldifs and removing ldifs.

> Integrate OpenDS in HEAD testsuite
> ----------------------------------
>
>                 Key: SECURITY-5
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule
> Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.
> My prelim testing details:
> ====================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
> [12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
>  Directory Server 0.1-build007 starting up."
> [12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
> database backend containing 1 entries has started."
> [12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
> msg="Access control has been disabled."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
> rectory Server has started successfully."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
> rectory Server has sent an alert notification generated by class org.opends.serv
> er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
> ert ID 458887):  The Directory Server has started successfully.."
> ================================================================================
> =============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
> -D "cn=Directory Manager" -w password -a -f a.ldif
> Processing ADD request for dc=jboss,dc=org.
> ADD operation successful for DN dc=jboss,dc=org.
> Processing ADD request for ou=People,dc=jboss,dc=org.
> ADD operation successful for DN ou=People,dc=jboss,dc=org.
> Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.
> ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.
> Processing ADD request for ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ===============================================================================
> ==============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
>  -b "dc=jboss,dc=org" -s sub "objectclass=*"
> dn: dc=jboss,dc=org
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o: JBoss
> dc: jboss
> dn: ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: person
> objectClass: uidObject
> userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
> cn: Java Duke
> sn: Duke
> uid: jduke
> =====================================================================================
> The application policy:
> <application-policy name = "jmx-console">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
>                           flag="required">
>                 <module-option name="java.naming.factory.initial"> 
>                     com.sun.jndi.ldap.LdapCtxFactory
>                     </module-option>
>                 <module-option name="java.naming.provider.url">
>                     ldap://localhost:389/
>                 </module-option>
>                 <module-option name="java.naming.security.authentication">
>                     simple
>                 </module-option>
>                 <module-option name="principalDNPrefix">uid=</module-option>                    
>                 <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
>                 <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
>                 <module-option name="uidAttributeID">member</module-option>
>                 <module-option name="matchOnUserDN">true</module-option>
>                 <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false</module-option>
>                 <module-option name="searchTimeLimit">5000</module-option>
>                 <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
>             </login-module>
>         </authentication>
>     </application-policy>

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:32:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 17:32:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3588) Add system property
 to configure multiplexer stack
In-Reply-To: <8708084.1156955383873.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14073117.1158269554537.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3588?page=all ]

Brian Stansberry closed JBAS-3588.
----------------------------------

    Resolution: Done

Property is jboss.multiplexer.stack.  Default is "udp"

> Add system property to configure multiplexer stack
> --------------------------------------------------
>
>                 Key: JBAS-3588
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3588
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> Add system property jboss.multiplexer.stack and use it in the various config files to select the stack.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:34:35 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 17:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3639) Lookup fails during
	failover
In-Reply-To: <8989834.1157983952060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4724034.1158269675057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3639?page=all ]

Brian Stansberry resolved JBAS-3639.
------------------------------------

    Resolution: Rejected

Problem was the singleton was doing the lookup before the HA-JMS server had failed over and bound XAConnectionFactory.  Solved with a retry loop.

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBAS-3639
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3639
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.6 Final, JBossAS-4.0.4RC1
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534)
> This happened on our test cluster.
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.
> I tested with jboss 4.0.4 and the problem still exists

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:52:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 14 Sep 2006 17:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18430300.1158270754800.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=all ]

Bill Burke closed EJBTHREE-679.
-------------------------------

    Resolution: Done

open a different ticket if you need a furth extension please.  Thanks.

> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:52:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 14 Sep 2006 17:52:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-641) entitymanager is
 null then using @WebService and @Stateless annotations in one class
Message-ID: <2723765.1158270755289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-641?page=all ]

Bill Burke updated EJBTHREE-641:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> entitymanager is null then using @WebService and @Stateless annotations in one class
> ------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-641
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-641
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Ramil Israfilov
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I have a class with both @Stateless and @WebService annotation and injected entitymanager:
> @WebService(name = "WebServiceTest", 
>         targetNamespace = "http://accesspoint.jc/server" )
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
> @BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
> @Remote(ServerInterface.class)
> public class Server implements ServerInterface {
>       @PersistenceContext(unitName="CertiOneAccessPoint")
> 	EntityManager em;
>     @WebMethod
>     public SessionResponse createSession(SessionRequest sessionRequest) {
>         log.debug("sessionRequest"+sessionRequest);
>         SessionResponse resp = new SessionResponse();
>         Session session = new Session();
>         session=(Session) em.persist(session);
>         resp.setSessionId(session.getId());
>         return resp;
>     }
> }
> I can successfully package and deploy EAR file.
> If I access EJB3 bean from remote application using JNDI lookup then everything works ok.
> But if I try to access webservice I got null pointer exception on line: session=(Session) em.persist(session);
> 2006-06-29 17:24:02,815 DEBUG [be.certipost.jc.accesspoint.server.impl.Server] sessionRequestbe.certipost.jc.accesspoint.server.SessionRequest at fbf04a
> 2006-06-29 17:24:02,815 ERROR [STDERR] java.lang.NullPointerException
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at be.certipost.jc.accesspoint.server.impl.Server.createSession(Server.java:51)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:585)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:127)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:247)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:139)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:211)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:161)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:49)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 2006-06-29 17:24:02,831 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 18:30:35 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 18:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3587) Add a system
 property to configure TCPPING.initial_hosts
In-Reply-To: <19247726.1156955263825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14809038.1158273035602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3587?page=all ]

Brian Stansberry updated JBAS-3587:
-----------------------------------

    Fix Version/s:     (was: JBossAS-4.0.6.CR1)

Only for 5.0 as this kind of config only makes sense with the multiplexer.  If two separate TCP channels used the same property, that would make a mess.  

For 4.0.x users of course can create their own property and add it to their config files; we just won't ship with the config files already set up that way.

> Add a system property to configure TCPPING.initial_hosts
> --------------------------------------------------------
>
>                 Key: JBAS-3587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:
> <TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...
> For now I'm going to go with just a system property.  If people want a startup switch they can request it.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 20:58:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 14 Sep 2006 20:58:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-702) Quartz Timer
 Service in E-EJB3 hangs process, exception on shutdown
Message-ID: <1150389.1158281915419.JavaMail.jira@cloud.prod.atl2.jboss.com>

Quartz Timer Service in E-EJB3 hangs process, exception on shutdown
-------------------------------------------------------------------

                 Key: EJBTHREE-702
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-702
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: Bill Burke
         Assigned To: Carlo de Wolf
             Fix For: EJB 3.0 RC10 - FD


to test this out:

build embedded.dist
go run one of the tutorials.  You will see that the applicatoin will never exit.  I'm guessing this is becuase a Quartz thread is a non-daemon thread and holding up the exit of the process.  Also there is a NullPointerException on shutdown.  I have disabled the Quartz Timer Service in embedded-jboss-beans.xml for now.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 22:33:40 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Thu, 14 Sep 2006 22:33:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (EJBTHREE-703) <security-domain>
 setting in
 deployment descriptor populates @SecurityDomain annotation incorrectly on
 EJB3 session beans
In-Reply-To: <12582259.1157495069506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5539658.1158287620175.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-703?page=all ]

Scott M Stark moved JBAS-3624 to EJBTHREE-703:
----------------------------------------------

              Project: EJB 3.0  (was: JBoss Application Server)
                  Key: EJBTHREE-703  (was: JBAS-3624)
          Component/s:     (was: EJB3)
    Affects Version/s:     (was: JBossAS-4.0.4.GA)

> <security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-703
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-703
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: David Green
>         Assigned To: Bill Burke
>
> Specifying a <security-domain> in the jboss-app.xml incorrectly sets the @SecurityDomain on EJB3 session beans.
> In the jboss-app.xml the security domain is specified as follows:
> <jboss-app>
> 	<security-domain>java:/jaas/hch</security-domain>
> </jboss-app>
> In Ejb3DescriptorHandler the security-domain is copied directly into the SecurityDomainImpl instance as "java:/jaas/hch", however the @SecurityDomain annotation should be populated with the value "hch" (without the leading "java:/jaas/" prefix).  This causes the EJB3 session bean authentication to behave unexpectedly, since the authentication for the bean reverts to the default domain instead of the specified one.
> The only way I've found to workaround this issue is to specify the @SecurityDomain individually on every session bean in the project.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 22:49:34 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Thu, 14 Sep 2006 22:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-364) Secured JBoss
 server configured via 'JBoss Server View' fail to Start/Debug
In-Reply-To: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2758406.1158288574034.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-364?page=comments#action_12343348 ] 
            
Robert Stryker commented on JBIDE-364:
--------------------------------------

A Twiddle launch tab has been added to the server's launch configuration so that user/pass can be added to execution arguments. 

> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-364
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200
> JBoss-4.0.4.GA
> jdk1.5.0_06
> MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
> jmx-console also secured with the same security Domain.
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>
> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
> - MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
> has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
>    <descriptors>
>       <interceptors>
>          <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
>             securityDomain="java:/jaas/jmx-console"/>
>       </interceptors>
>    </descriptors>
> Im assuming that the 'jmx-console' is also secured with the same security Domain.
> Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
> on the server.

-- 
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

       



From jira-events at jboss.com  Thu Sep 14 22:51:34 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Thu, 14 Sep 2006 22:51:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-364) Secured JBoss server
 configured via 'JBoss Server View' fail to Start/Debug
In-Reply-To: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30660994.1158288694085.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-364?page=all ]

Robert Stryker closed JBIDE-364.
--------------------------------

    Fix Version/s: 2.0.0.Beta3
       Resolution: Done

> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-364
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200
> JBoss-4.0.4.GA
> jdk1.5.0_06
> MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
> jmx-console also secured with the same security Domain.
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>             Fix For: 2.0.0.Beta3
>
>
> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
> - MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
> has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
>    <descriptors>
>       <interceptors>
>          <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
>             securityDomain="java:/jaas/jmx-console"/>
>       </interceptors>
>    </descriptors>
> Im assuming that the 'jmx-console' is also secured with the same security Domain.
> Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
> on the server.

-- 
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

       



From jira-events at jboss.com  Thu Sep 14 22:51:34 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Thu, 14 Sep 2006 22:51:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-303) Custom JBoss
 configuration wizard (ala JBoss installer)
Message-ID: <26003123.1158288694247.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-303?page=all ]

Robert Stryker closed JBIDE-303.
--------------------------------

    Resolution: Rejected

Feature decided against. 

> Custom JBoss configuration wizard (ala JBoss installer)
> -------------------------------------------------------
>
>                 Key: JBIDE-303
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-303
>             Project: JBoss IDE
>          Issue Type: Feature Request
>          Components: JBossAS Adapter
>            Reporter: Marshall Culpepper
>         Assigned To: Robert Stryker
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Create a configuration wizard similar to the JBoss installation wizard that would allow the user to create a custom JBoss configuration from a standard JBoss installation.
> Some ideas:
> - Automatically secure jmx/admin consoles
> - install/don't install certain services

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 23:05:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 23:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
Message-ID: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>

JDBCCacheLoader should not directly serialize a map passed to put
-----------------------------------------------------------------

                 Key: JBCACHE-769
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 1.4.0.SP1, 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.2.4SP2, 1.2.4SP1, 1.2.4, 1.2.3
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
            Priority: Minor


If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.

Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.

Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.

The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 23:33:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 23:33:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30140479.1158291214382.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Fix Version/s: 2.0.0
         Assignee: Brian Stansberry  (was: Manik Surtani)

JDBCCacheLoader is fixed; need to check the other cache loaders.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 00:55:34 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 15 Sep 2006 00:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1039) Producer NPE
 when no namespace prefix is provided in RuntimeContext.
Message-ID: <1442646.1158296134469.JavaMail.jira@cloud.prod.atl2.jboss.com>

Producer NPE when no namespace prefix is provided in RuntimeContext.
--------------------------------------------------------------------

                 Key: JBPORTAL-1039
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1039
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1


When creating the WindowContext for the invocation in MarkupHandler, we are relying on the precense of namespacePrefix in the passed RuntimeContext. NamespacePrefix is optional in WSRP 1.0.
On the flip side, we should also provide that information when creating markup requests on the Consumer.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 00:55:34 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 15 Sep 2006 00:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1039) Producer NPE
 when no namespace prefix is provided in RuntimeContext.
In-Reply-To: <1442646.1158296134469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22566037.1158296134547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1039?page=all ]

Chris Laprun updated JBPORTAL-1039:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89851

> Producer NPE when no namespace prefix is provided in RuntimeContext.
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1039
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1039
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>
> When creating the WindowContext for the invocation in MarkupHandler, we are relying on the precense of namespacePrefix in the passed RuntimeContext. NamespacePrefix is optional in WSRP 1.0.
> On the flip side, we should also provide that information when creating markup requests on the Consumer.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 01:35:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 01:35:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-319) -props ./udp.xml
 finds udp.xml in classpath *before* file ./udp.xml
Message-ID: <25571427.1158298534007.JavaMail.jira@cloud.prod.atl2.jboss.com>

-props ./udp.xml finds udp.xml in classpath *before* file ./udp.xml
-------------------------------------------------------------------

                 Key: JGRP-319
                 URL: http://jira.jboss.com/jira/browse/JGRP-319
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


If we explicitly define a relative path for a config file, then we must honor it, so find ./udp.xml *before* udp.xml in the classpath

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 01:43:34 2006
From: jira-events at jboss.com (Sohui Gu (JIRA))
Date: Fri, 15 Sep 2006 01:43:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29061995.1158299014677.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=comments#action_12343352 ] 
            
Sohui Gu commented on JBSEAM-347:
---------------------------------

[#|2006-09-15T13:25:27.468+0800|SEVERE|sun-appserver-pe8.2|org.apache.pluto.invoker.impl.PortletInvokerImpl|_ThreadID=16;|PortletInvokerImpl.render() - Error while dispatching portlet.
javax.portlet.PortletException: java.lang.IllegalStateException: No active conversation context
	at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:341)
	at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:205)
	at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:145)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:140)
	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.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
	at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:105)
	at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
	at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
	at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:75)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:159)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:281)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)
	at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)
	at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)
Caused by: javax.faces.el.EvaluationException: java.lang.IllegalStateException: No active conversation context
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:206)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:154)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:753)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:728)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:278)
	at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:59)
	at com.sun.faces.portlet.ViewHandlerImpl.renderView(ViewHandlerImpl.java:132)
	at com.sun.faces.portlet.LifecycleImpl$RenderResponsePhase.execute(LifecycleImpl.java:702)
	at com.sun.faces.portlet.LifecycleImpl.phase(LifecycleImpl.java:323)
	at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:244)
	at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:327)
	... 171 more
Caused by: java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Process.instance(Process.java:32)
	at org.jboss.seam.core.TaskInstance.instance(TaskInstance.java:51)
	at org.jboss.seam.contexts.BusinessProcessContext.getTaskInstance(BusinessProcessContext.java:213)
	at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:51)
	at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:155)
	at org.jboss.seam.Component.getInstance(Component.java:1245)
	at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
	at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
	at com.sun.faces.el.impl.NamedValue.evaluate(NamedValue.java:125)
	at com.sun.faces.el.impl.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:243)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:173)
	... 181 more

Nested Exception is javax.faces.el.EvaluationException: java.lang.IllegalStateException: No active conversation context
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:206)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:154)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:753)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:728)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:278)
	at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:59)
	at com.sun.faces.portlet.ViewHandlerImpl.renderView(ViewHandlerImpl.java:132)
	at com.sun.faces.portlet.LifecycleImpl$RenderResponsePhase.execute(LifecycleImpl.java:702)
	at com.sun.faces.portlet.LifecycleImpl.phase(LifecycleImpl.java:323)
	at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:244)
	at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:327)
	at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:205)
	at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:145)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:140)
	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.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
	at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:105)
	at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
	at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
	at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:75)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:159)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:281)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)
	at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)
	at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)
Caused by: java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Process.instance(Process.java:32)
	at org.jboss.seam.core.TaskInstance.instance(TaskInstance.java:51)
	at org.jboss.seam.contexts.BusinessProcessContext.getTaskInstance(BusinessProcessContext.java:213)
	at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:51)
	at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:155)
	at org.jboss.seam.Component.getInstance(Component.java:1245)
	at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
	at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
	at com.sun.faces.el.impl.NamedValue.evaluate(NamedValue.java:125)
	at com.sun.faces.el.impl.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:243)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:173)
	... 181 more
|#]


> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 02:17:33 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Fri, 15 Sep 2006 02:17:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2442603.1158301053366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3494?page=all ]

Scott M Stark closed JBAS-3494.
-------------------------------

    Resolution: Done

It was just an issue with when the method signature classes were loaded. Just invoking getMethods under jrockit was not loading the method throws classes. The test was updated to explicitly attempt to obtain the exception clause classes.

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, ClassLoading
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 02:37:35 2006
From: jira-events at jboss.com (Uhyon Chung (JIRA))
Date: Fri, 15 Sep 2006 02:37:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-750) NPE on
 TaskInstance.java on end()
 when TaskInstance created manually and no Task is assigned
Message-ID: <30850656.1158302255345.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE on TaskInstance.java on end() when TaskInstance created manually and no Task is assigned
--------------------------------------------------------------------------------------------

                 Key: JBPM-750
                 URL: http://jira.jboss.com/jira/browse/JBPM-750
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: All
            Reporter: Uhyon Chung
         Assigned To: Tom Baeyens


When you create a new TaskInstance manually (from a ActionHandler) without a Task assigned, an NPE occurs in a log statement in the end(Transition) method.

If you take a look at the end method, it seems to allow null tasks, because it checks whether the task is null before execution methods on the task field. However, in the log.debug statement, it does not do this null check, which causes an NPE. I'm not quite sure if having a TaskInstance without a Task is really a good practice, but otherwise I would need to create a Task object and add it to the ProcessDefinition, which is definitely not something I want to be doing since I just want to add a task instance to the user's task list dynamically.

I've created a small fix, and the patch is as follows.I made the patch based on the 3.1.2 on CVS using Eclipse patch.


### Eclipse Workspace Patch 1.0
#P jbpm3
Index: jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java
===================================================================
RCS file: /cvsroot/jbpm/jbpm.3/jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java,v
retrieving revision 1.6
diff -u -r1.6 TaskInstance.java
--- jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java	8 Sep 2006 11:23:07 -0000	1.6
+++ jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java	15 Sep 2006 06:27:07 -0000
@@
         if (transition==null) {
-          log.debug("completion of task '"+task.getName()+"' results in taking the default transition");
+          log.debug("completion of task '"+(task==null?getName():task.getName())+"' results in taking the default transition");
           token.signal();
         } else {
-          log.debug("completion of task '"+task.getName()+"' results in taking transition '"+transition+"'");
+          log.debug("completion of task '"+(task==null?getName():task.getName())+"' results in taking transition '"+transition+"'");
           token.signal(transition);
         }
       }
 -464,10 +464,10 @@
          ) {

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 03:21:35 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Fri, 15 Sep 2006 03:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-186) Write a blog entry
 about the beta release
Message-ID: <10190413.1158304895499.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-186?page=comments#action_12343355 ] 
            
Alejandro Guizar commented on BPEL-186:
---------------------------------------

Blog published: http://tinyurl.com/hjj4c

> Write a blog entry about the beta release
> -----------------------------------------
>
>                 Key: BPEL-186
>                 URL: http://jira.jboss.com/jira/browse/BPEL-186
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 03:37:34 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Fri, 15 Sep 2006 03:37:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-122) Links should be
	recognized
Message-ID: <8232553.1158305854518.JavaMail.jira@cloud.prod.atl2.jboss.com>

Links should be recognized
--------------------------

                 Key: JBFORUMS-122
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-122
             Project: JBoss Forums
          Issue Type: Feature Request
          Components: Forum Enhancements
            Reporter: Thomas Diesler
         Assigned To: Sohil Shah


Instead of 

[url]http://jira.jboss.com/jira/secure/CreateIssue.jspa[/url]

I like to simply use

http://jira.jboss.com/jira/secure/CreateIssue.jspa

There are a lot of user provided links that I cannot click on.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 04:41:36 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 04:41:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-704) Missing
 privileged action to get Principal
Message-ID: <23329041.1158309696237.JavaMail.jira@cloud.prod.atl2.jboss.com>

Missing privileged action to get Principal 
-------------------------------------------

                 Key: EJBTHREE-704
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-704
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Roland R?z


The method  org.jboss.ejb3.BaseSessionContext.getCallerPrincipal should use a privileged action  instead of SecurityAssociation.getCallerPrincipal(). 

@see http://jira.jboss.com/jira/browse/JBAOP-95


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 04:43:35 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 04:43:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-705) Pluggable default
 naming conventions for ejb3 jndi bindings
Message-ID: <1871287.1158309815074.JavaMail.jira@cloud.prod.atl2.jboss.com>

Pluggable default naming conventions for ejb3 jndi bindings
-----------------------------------------------------------

                 Key: EJBTHREE-705
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-705
             Project: EJB 3.0
          Issue Type: Feature Request
            Reporter: Roland R?z
            Priority: Minor


Currently the org.jboss.ejb3.ProxyFactoryHelper uses the [<earname>/]<ejbname>/[remote|local] naming convention. 

An Interface could provide the default names for jndi binding when the deployer doesn't provide them.

The interface could look like this: 

public interface DefaultJndiNameProvider { 
   String getDefaultRemoteJndiName(Container container); 
   String getDefaultLocalJndiName(Container container); 
} 


The implementation of the DefaultJndiNameProvider could be configured using a System Property.


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 05:13:42 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 15 Sep 2006 05:13:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-495) Allows for
 automatic meta data
 gathering during rule/rule package saves to repository
In-Reply-To: <32823093.1158253481712.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11206429.1158311622136.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-495?page=all ]

Michael Neale reassigned JBRULES-495:
-------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Allows for automatic meta data gathering during rule/rule package saves to repository
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-495
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-495
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Marcos Tengelmann
>         Assigned To: Michael Neale
>            Priority: Optional
>
> In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.
> The whole idea here is to keep the concept of Category only for business purposes.
> Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions
> With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 05:15:37 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 05:15:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-705) Pluggable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <1871287.1158309815074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28273567.1158311737967.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-705?page=comments#action_12343357 ] 
            
Roland R?z commented on EJBTHREE-705:
-------------------------------------

We need a different naming convention to support multiple jboss instances which can use services from each other. The instances are linked to each other using jndi links und rely on naming conventions. 

With a pluggable jndi name provider we could get rid of the "pain" from configuring the jndi name for each bean. It would be fine when the "Configuration by Exception" rule applies also in more complex environments.


> Pluggable default naming conventions for ejb3 jndi bindings
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-705
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-705
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>            Priority: Minor
>
> Currently the org.jboss.ejb3.ProxyFactoryHelper uses the [<earname>/]<ejbname>/[remote|local] naming convention. 
> An Interface could provide the default names for jndi binding when the deployer doesn't provide them.
> The interface could look like this: 
> public interface DefaultJndiNameProvider { 
>    String getDefaultRemoteJndiName(Container container); 
>    String getDefaultLocalJndiName(Container container); 
> } 
> The implementation of the DefaultJndiNameProvider could be configured using a System Property.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 05:17:46 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 15 Sep 2006 05:17:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-495) Allows for
 automatic meta
 data gathering during rule/rule package saves to repository
In-Reply-To: <32823093.1158253481712.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25167803.1158311866363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-495?page=comments#action_12343358 ] 
            
Michael Neale commented on JBRULES-495:
---------------------------------------

This woudl apply to any rule change/save. 

The meta data would need to be refreshed.

We could use a structure like

     RuleNode
   /                  
ColumnNode      
-field list (String[])
-name

> Allows for automatic meta data gathering during rule/rule package saves to repository
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-495
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-495
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Marcos Tengelmann
>         Assigned To: Michael Neale
>            Priority: Optional
>
> In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.
> The whole idea here is to keep the concept of Category only for business purposes.
> Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions
> With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 06:42:41 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Fri, 15 Sep 2006 06:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11240801.1158316961975.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=comments#action_12343359 ] 
            
Manik Surtani commented on JBCACHE-769:
---------------------------------------

Do we want to backport this for 1.4.x as well?

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 07:04:36 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 15 Sep 2006 07:04:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-497) Joda datetime API
	integration
Message-ID: <32125869.1158318276385.JavaMail.jira@cloud.prod.atl2.jboss.com>

Joda datetime API integration
-----------------------------

                 Key: JBRULES-497
                 URL: http://jira.jboss.com/jira/browse/JBRULES-497
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: All
            Reporter: Michael Neale
         Assigned To: Mark Proctor


http://joda-time.sourceforge.net/userguide.html

Would be VERY nice to have this working at the parser level to parser dates in a string, but also possibly in our expression language to overload "+", "-" etc for subtracting dates/fragments of dates:

eg:

today - "6Months" 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:08:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 08:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-320)
 ConnectionTable/ConnectionTableNIO
 have leftover threads after stop()
Message-ID: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>

ConnectionTable/ConnectionTableNIO have leftover threads after stop()
---------------------------------------------------------------------

                 Key: JGRP-320
                 URL: http://jira.jboss.com/jira/browse/JGRP-320
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


Unit test ConnectionTableTest shows this.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:08:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 08:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21076134.1158322113915.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-320?page=comments#action_12343362 ] 
            
Bela Ban commented on JGRP-320:
-------------------------------

ConnectionTable has been fixed.
ConnectionTableNIO still fails if the sleep(1000) towards the end of the method is removed

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:22:33 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:22:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3643) null message blob is
 created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
In-Reply-To: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9858717.1158322953967.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3643?page=all ]

Adrian Brock closed JBAS-3643.
------------------------------

    Resolution: Duplicate Issue

No, you can use search just as well as I can.
All this post does is pollute that search index. I will delete it in a few days.

> null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Windows XP, Oracle 9.2.0.5
>            Reporter: Edward Lu
>            Priority: Critical
>
> A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):
> I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.
> Your help is highly appreciated.
> ****************************************************************************************
> SQL> select count(*) from jms_messages where messageblob is null;
>   COUNT(*)
> ----------
>          3
> *******************************************************************************************
> 2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
> org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
> (java.lang.NullPointerException)^M
>         at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
>         at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
>         at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
>         at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M
> ......
> ......
> Caused by: java.lang.NullPointerException^M
>         at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
>         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
>         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
>         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
>         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M
> *******************************************************************************************************************

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:24:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 08:24:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-320)
 ConnectionTable/ConnectionTableNIO
 have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18671278.1158323074048.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-320?page=all ]

Bela Ban updated JGRP-320:
--------------------------

    Description: 
Unit test ConnectionTableTest shows this, use the following system properties:
-Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]


  was:Unit test ConnectionTableTest shows this.


> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:26:33 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2566) Remove public
 interface changes from HEAD
Message-ID: <6333807.1158323193352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2566?page=all ]

Adrian Brock closed JBAS-2566.
------------------------------

    Resolution: Done
      Assignee: Adrian Brock  (was: Elias Ross)

No, I fixed this in the latest synchronization of the 4.0.x and 5.0.x trees.
This removed the addition of the ThreadPool to the invoker/interceptor interfaces
which should be handled in the same way as the 
org.jboss.mq.Recoverable interface I added.

> Remove public interface changes from HEAD
> -----------------------------------------
>
>                 Key: JBAS-2566
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2566
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Elias Ross
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:28:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:28:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2575) Hibernate usage in
	JBoss Messaging
Message-ID: <6076094.1158323316492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2575?page=all ]

Adrian Brock closed JBAS-2575.
------------------------------

    Resolution: Rejected

Steve, you need to reopen this issue in the messaging project.
I cannot move this issue there since it is a subtask?

> Hibernate usage in JBoss Messaging
> ----------------------------------
>
>                 Key: JBAS-2575
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2575
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Steve Ebersole
>         Assigned To: Steve Ebersole
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Currently, JBoss Messaging is going down the path of pluggable "persistence managers" attempted by JBossMQ in order to achieve database portability.  As discussed numerous times, we should introduce Hibernate here to achieve this portability rather than maintaining all this stuff for the various databases.  Plus would give Messaging a much easier way to introduce some of the other benefits/features of using Hibernate (caching, 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

        


From jira-events at jboss.com  Fri Sep 15 08:30:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-2575) Hibernate usage in
 JBoss Messaging
Message-ID: <16864766.1158323435016.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2575?page=all ]

Adrian Brock reopened JBAS-2575:
--------------------------------

             

> Hibernate usage in JBoss Messaging
> ----------------------------------
>
>                 Key: JBAS-2575
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2575
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Steve Ebersole
>         Assigned To: Steve Ebersole
>
> Currently, JBoss Messaging is going down the path of pluggable "persistence managers" attempted by JBossMQ in order to achieve database portability.  As discussed numerous times, we should introduce Hibernate here to achieve this portability rather than maintaining all this stuff for the various databases.  Plus would give Messaging a much easier way to introduce some of the other benefits/features of using Hibernate (caching, 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

        


From jira-events at jboss.com  Fri Sep 15 08:30:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2575) Hibernate usage in
	JBoss Messaging
Message-ID: <4070594.1158323435144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2575?page=all ]

Adrian Brock closed JBAS-2575.
------------------------------

    Fix Version/s:     (was: JBossAS-5.0.0.Beta)
       Resolution: Rejected

> Hibernate usage in JBoss Messaging
> ----------------------------------
>
>                 Key: JBAS-2575
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2575
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Steve Ebersole
>         Assigned To: Steve Ebersole
>
> Currently, JBoss Messaging is going down the path of pluggable "persistence managers" attempted by JBossMQ in order to achieve database portability.  As discussed numerous times, we should introduce Hibernate here to achieve this portability rather than maintaining all this stuff for the various databases.  Plus would give Messaging a much easier way to introduce some of the other benefits/features of using Hibernate (caching, 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

        


From jira-events at jboss.com  Fri Sep 15 08:34:37 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:34:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3091) Session recycle bug in
 org.jboss.jms.asf.StdServerSession
Message-ID: <28297136.1158323677058.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3091?page=all ]

Adrian Brock closed JBAS-3091.
------------------------------

    Fix Version/s:     (was: JBossAS-4.0.6.CR1)
       Resolution: Won't Fix

This issue is replaced by the rewrite of the session pool on the linked task.

> Session recycle bug in org.jboss.jms.asf.StdServerSession
> ---------------------------------------------------------
>
>                 Key: JBAS-3091
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3091
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Roland R?z
>
> If a JMS provider throws an unchecked Exception out of Session.run(), the method org.jboss.jms.asf.StdServerSession.run() does recycled the Session without making a rollback on the Session before. If the next message on this recycled Session will be commited the older Message which has been already consumed from the Messaging System before when throwing the Exception will be lost. Because of the Exception this older Message has neither been rollbacked nor committed before.
> To avoid this problem a Session.rollback() needs to be called before recycling it in case of any unchecked Exception. (See code snippet below!)
> Possible Fix:
> public void run()
>    {
>       boolean trace = log.isTraceEnabled();
>       if (trace)
>          log.trace("running...");
>       try
>       {
>          if (xaSession != null)
>             xaSession.run();
>          else
>             session.run();
>       }      
>       // To avoid loosing Messages rollback the Session in case of any Exception from the JMS provider
>       catch (Throwable e) {
>           log.error("Exception occured during the Session.run(). Call Session.rollback() before recycling it.", e);
>           try {
>               if (xaSession != null)
>                   xaSession.rollback();
>                else
>                   session.rollback();
>           }
>           catch (JMSException ex) {
>               log.error("Exception occured when calling Session.rollback()", e);
>           }
>       }
>       finally
>       {
>          if (trace)
>             log.trace("recycling...");
>         
>          recycle();
>          if (trace)
>             log.trace("finished run");
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:36:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2409) EJB3 JMS Integration
Message-ID: <16868672.1158323795166.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2409?page=all ]

Adrian Brock reassigned JBAS-2409:
----------------------------------

    Assignee: William DeCoste

Assigned to Bill to update the status.

> EJB3 JMS Integration
> --------------------
>
>                 Key: JBAS-2409
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2409
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>         Assigned To: William DeCoste
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Need to determine whether the legacy JMS MDB integration using ServerSessionPools directly
> needs to be refactored to cover both EJB2.1 and EJB3.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

        


From jira-events at jboss.com  Fri Sep 15 08:36:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2150) Disable automatic
 JBossMQ destination construction
Message-ID: <16504128.1158323795295.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2150?page=all ]

Adrian Brock updated JBAS-2150:
-------------------------------

    Comment: was deleted

> Disable automatic JBossMQ destination construction
> --------------------------------------------------
>
>                 Key: JBAS-2150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>             Fix For: No Release
>
>
> The automatic construction of JBossMQ destination construction is not portable
> and confuses most users when they configure things wrong.
> They don't get a reasonable error message, and sometimes no error message at all.
> This was made configurable in JBoss4 and should be disabled in JBoss5
> See conf/standardjboss.xml
> -        <CreateJBossMQDestination>true</CreateJBossMQDestination>
> +        <CreateJBossMQDestination>false</CreateJBossMQDestination>
> The testsuite will need fixing for any MDB deployments that were using this feature
> to have explicit destination deployments. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:38:34 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2150) Disable automatic
 JBossMQ destination construction
Message-ID: <29169316.1158323914705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2150?page=all ]

Adrian Brock closed JBAS-2150.
------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                       (was: No Release)
       Resolution: Done
         Assignee: Adrian Brock

This was done a while ago in JBoss5.

> Disable automatic JBossMQ destination construction
> --------------------------------------------------
>
>                 Key: JBAS-2150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The automatic construction of JBossMQ destination construction is not portable
> and confuses most users when they configure things wrong.
> They don't get a reasonable error message, and sometimes no error message at all.
> This was made configurable in JBoss4 and should be disabled in JBoss5
> See conf/standardjboss.xml
> -        <CreateJBossMQDestination>true</CreateJBossMQDestination>
> +        <CreateJBossMQDestination>false</CreateJBossMQDestination>
> The testsuite will need fixing for any MDB deployments that were using this feature
> to have explicit destination deployments. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:38:34 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 08:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-706)
 NullPointerException in
 RunAsSecurityInterceptorFactory when there is no SecurityDomain annotation
Message-ID: <18518904.1158323914812.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException in RunAsSecurityInterceptorFactory when there is no SecurityDomain annotation
--------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-706
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-706
             Project: EJB 3.0
          Issue Type: Bug
          Components: Security
            Reporter: Roland R?z
            Priority: Minor


The class org.jboss.ejb3.security.RunAsSecurityInterceptorFactory throws in createPerClass() a NullPointerException when there is no SecurityDomain annotation.

Possible Fix:
if (securityAnnotation != null) {
  domain = ctx.lookup("java:/jaas/" + securityAnnotation.value());
}


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:35 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 15 Sep 2006 08:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2759919.1158324515796.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3597?page=all ]

Dimitris Andreadis updated JBAS-3597:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Unlikely to get done for 4.0.5

Started a thread in case those tests can be unified with JBM:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971910#3971910

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2156) Patch to add expiry
 queue support to JBossMQ
Message-ID: <32179663.1158324516164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2156?page=all ]

Adrian Brock updated JBAS-2156:
-------------------------------

    Fix Version/s:     (was: No Release)

> Patch to add expiry queue support to JBossMQ
> --------------------------------------------
>
>                 Key: JBAS-2156
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2156
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Elias Ross
>         Assigned To: Elias Ross
>         Attachments: expiry.diff, expiry.diff, expiry.txt, ExpiryDestinationTestCase.java
>
>
> Added attributes "ExpiryDestination" to DestinationMBean and DestinationManagerMBean to indicate an ObjectName of queue to receive expired messages. This destination queue must be bound into JNDI when this queue starts.
> The messages are copied over to this queue when expiry time is reached and the original expiration and destination is kept in the vendor parameters "JBOSS_ORIG_EXPIRATION" and "JBOSS_ORIG_DESTINATION". The same JMSMessageID is kept in the copied message.
> The limitation of this is that the queue must be located on the same local JBoss server.
> Another limitation is that the expired message is only removed after its copy has been added to the new destination. Ideally, the "move" would happen within a single transaction.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2156) Patch to add expiry
 queue support to JBossMQ
Message-ID: <16531854.1158324516298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2156?page=all ]

Adrian Brock updated JBAS-2156:
-------------------------------

    Comment: was deleted

> Patch to add expiry queue support to JBossMQ
> --------------------------------------------
>
>                 Key: JBAS-2156
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2156
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Elias Ross
>         Assigned To: Elias Ross
>         Attachments: expiry.diff, expiry.diff, expiry.txt, ExpiryDestinationTestCase.java
>
>
> Added attributes "ExpiryDestination" to DestinationMBean and DestinationManagerMBean to indicate an ObjectName of queue to receive expired messages. This destination queue must be bound into JNDI when this queue starts.
> The messages are copied over to this queue when expiry time is reached and the original expiration and destination is kept in the vendor parameters "JBOSS_ORIG_EXPIRATION" and "JBOSS_ORIG_DESTINATION". The same JMSMessageID is kept in the copied message.
> The limitation of this is that the queue must be located on the same local JBoss server.
> Another limitation is that the expired message is only removed after its copy has been added to the new destination. Ideally, the "move" would happen within a single transaction.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2156) Patch to add expiry
 queue support to JBossMQ
Message-ID: <22463417.1158324516409.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2156?page=all ]

Adrian Brock updated JBAS-2156:
-------------------------------

    Comment: was deleted

> Patch to add expiry queue support to JBossMQ
> --------------------------------------------
>
>                 Key: JBAS-2156
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2156
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Elias Ross
>         Assigned To: Elias Ross
>         Attachments: expiry.diff, expiry.diff, expiry.txt, ExpiryDestinationTestCase.java
>
>
> Added attributes "ExpiryDestination" to DestinationMBean and DestinationManagerMBean to indicate an ObjectName of queue to receive expired messages. This destination queue must be bound into JNDI when this queue starts.
> The messages are copied over to this queue when expiry time is reached and the original expiration and destination is kept in the vendor parameters "JBOSS_ORIG_EXPIRATION" and "JBOSS_ORIG_DESTINATION". The same JMSMessageID is kept in the copied message.
> The limitation of this is that the queue must be located on the same local JBoss server.
> Another limitation is that the expired message is only removed after its copy has been added to the new destination. Ideally, the "move" would happen within a single transaction.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:06:35 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 09:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-319) -props ./udp.xml
 finds udp.xml in classpath *before* file ./udp.xml
In-Reply-To: <25571427.1158298534007.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18326336.1158325595317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-319?page=all ]

Bela Ban resolved JGRP-319.
---------------------------

    Resolution: Done

> -props ./udp.xml finds udp.xml in classpath *before* file ./udp.xml
> -------------------------------------------------------------------
>
>                 Key: JGRP-319
>                 URL: http://jira.jboss.com/jira/browse/JGRP-319
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If we explicitly define a relative path for a config file, then we must honor it, so find ./udp.xml *before* udp.xml in the classpath

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:08:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:08:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
In-Reply-To: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32004285.1158325723393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3620?page=all ]

Adrian Brock reassigned JBAS-3620:
----------------------------------

    Assignee: Adrian Brock

> JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBossMQ's PersistenceManager has a mechanism to retry recovery
> a number of times "RecoveryRetries".
> However, this only applies to the data recovery. If it fails 
> (e.g. due to database or network glitch)
> while checking/creating the database schema
> then no retries are done.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1908) listMessageCounter
 issue with JMS
 subscriptions containing certain message selector characters
Message-ID: <32367233.1158325843431.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1908?page=all ]

Adrian Brock updated JBAS-1908:
-------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> listMessageCounter issue with JMS subscriptions containing certain message selector characters
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-1908
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1908
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP Professional, JDK1.4.2_06, JBoss 4.0.2
>            Reporter: Jaco Joubert
>            Priority: Minor
>         Attachments: DestinationManager.txt, DestinationMBeanSupport.txt, listCounter.jar, MessageCounter.txt, test-topic-service.xml
>
>
> When the message selector query for a subscription to a JMS topic looks someting like "field in ('A', 'B', 'C')", two failures occur on JMS MBeans:
> 1.  The listMessageCounter operation on jboss.mq:service=DestinationManager fails with a NumberFormatException:
> Caused by: java.lang.NumberFormatException: For input string: " 'ghi'"
>   at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>   at java.lang.Integer.parseInt(Integer.java:468)
>   at java.lang.Integer.parseInt(Integer.java:518)
>   at org.jboss.mq.server.jmx.DestinationManager.listMessageCounter(DestinationManager.java:477)
>   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:324)
>   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>   ... 44 more
> This is because the getCounterAsString() method is used on the MessageCounter to get the details and then traversed with
> a StringTokenizer tokenizing on commas, but the subscription name also contains commas in this case.
> 2.  The listMessageCounter operation on jboss.mq.destination:name=[topicName],service=Topic works, but the resulting HTML
>     table has some of the selector values populating the counter columns.  The problem is because of the same issue as above.
>     
> This can be reproduced by following these steps:
> 1.  Startup a JBoss4.0.2 with default configuration.
> 2.  Deploy the attached 'test-topic-service.xml'.  This will create a JMS topic called 'counterTestTopic'.
> 3.  Run the attached client (source included in jar).  The only jar needed on classpath is the 'jbossall-client.jar':
>     java -cp "[path]\jbossall-client.jar;.\listCounter.jar" za.co.jdj.jbossmq.testcounter.TestListCounter
>     This will do the following:
>     3.1.  Connect to the JMS server running locally.
>     3.2.  Create a publisher and durable subscriber on the 'counterTestTopic' already deployed.
>           The subscriber has a message selector in the format already described
>     3.3.  Invoke the listMessageCounter operation on jboss.mq:service=DestinationManager, printing the error.
>     3.4.  Wait for the client to look at the html table created by the topic in a browser.
>     3.5.  Remove the subscription and exit.
>     
> Suggested fixes for the problem includes:
> 1.  Add a getDestinationTypeDescription() method to org.jboss.mq.server.MessageCounter.  (See MessageCounter.txt attached)
> 2.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationManager to not use the getCounterAsString() method
>     on org.jboss.mq.server.MessageCounter, but rather extract the values itself for the html table.
>     (See the DestinationManager.txt file attached).
> 3.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationMBeanSupport to do the same as above.
>     (See the DestinationMBeanSupport.txt file attached).

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1346) JDBC StateManager
Message-ID: <26174295.1158325843984.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1346?page=all ]

Adrian Brock updated JBAS-1346:
-------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> JDBC StateManager
> -----------------
>
>                 Key: JBAS-1346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1346
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> The JDBC StateManager should have operations to create/delete users and subscriptions in the
> database, just like the old File StateManager did.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3468) JMS Connection
 starts ping
 thread before ClientID is set resulting in the ClientMonitorInterceptor to
 close the connection after client timeout
In-Reply-To: <11361240.1154691131936.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20555830.1158325844214.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]

Adrian Brock reassigned JBAS-3468:
----------------------------------

    Assignee: Adrian Brock

> JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3468
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3468
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP
>            Reporter: Francis Labaere
>         Assigned To: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection  is set (explicitely using setClientID or implicitely).   The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
> The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap.  When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one.  When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken.  Subsequent calls to the server will generate exceptions: User session is not valid.
> On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
> Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive: 
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
> 2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.'  This exception is being propogated to the client as a HTTPILResponse.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade at 2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade at 1343c2a)
> On the Client side: following stacktrace is visible
> 13:17:57 [MessageListenerThread - MyTopic] WARN  org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> mq.Connection should start the ping thread after the ClientID is known.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3483) The javadoc
 relating to StdServerSessionPool pooling parameters is wrong
In-Reply-To: <33330695.1154959692644.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13734637.1158325844412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3483?page=all ]

Adrian Brock reassigned JBAS-3483:
----------------------------------

    Assignee: Weston Price

> The javadoc relating to StdServerSessionPool pooling parameters is wrong
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3483
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3483
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The javadoc in the StdServerSessionPool constructor is misleading.
> It refers to the pool parameters controlling the number of sessions when it
> primarily controls the number of threads. Only the MaxPoolSize controls the number of sessions
> which are created at pool construction time.
> This WIKI page has it correct:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMDB

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter
 makes unnecessary temporary delete requests
Message-ID: <22957957.1158325844670.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ]

Adrian Brock updated JBAS-1485:
-------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> JMS ResourceAdapter makes unnecessary temporary delete requests
> ---------------------------------------------------------------
>
>                 Key: JBAS-1485
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1485
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1
>            Reporter: Adrian Brock
>            Priority: Optional
>
> The JMS ResourceAdaptor keeps track of temporaries created on a connection
> (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl)
> and deletes them.
> This is because we cannot expect the real JMS implementation to do this
> because the connection is pooled and not closed.
> However, if the user is deleting the temporaries themselves
> (good practice in terms of resource usage),
> the JMS ResourceAdapter does not know about this
> and tries to repeat the delete at connection.close();
> Solution:
> Add some wrapping processing for the temporary queues and topics
> so we can trap temporary.delete(). That way we will know we don't
> need to do it on close()
> IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will
> also need to trap these destinations to do the necessary wrapping/unwrapping.
> It is also possible to retrieve a temporary destination with Session.createQueue/Topic.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:12:39 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:12:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26467656.1158325959828.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Adrian Brock updated JBAS-3628:
-------------------------------

    Component/s: JMS service

> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Fri Sep 15 09:14:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:14:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7977366.1158326083620.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Adrian Brock reassigned JBAS-3628:
----------------------------------

    Assignee: Adrian Brock  (was: Luc Texier)

> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Fri Sep 15 09:42:36 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 15 Sep 2006 09:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3631) Missing branch in
 StdServerSession commit logic
In-Reply-To: <5722134.1157628523903.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20972896.1158327756438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3631?page=all ]

Weston Price resolved JBAS-3631.
--------------------------------

    Resolution: Done

Added transation branch to StdServerSession txn managment in onMessage. 

> Missing branch in StdServerSession commit logic
> -----------------------------------------------
>
>                 Key: JBAS-3631
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3631
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a missing branch in the StdServerSession commit logic.
> In the case where the transaction manager rollsback the transaction early,
> e.g. JBossTM does this for transaction timeouts, the status will be NO_TRANSACTION
> (or a heuristic state).
> The code:
>                // Marked rollback
>                if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK)
>                {
>                   if (trace)
>                      log.trace(StdServerSession.this + " rolling back JMS transaction tx=" + trans);
>                   // actually roll it back
>                   tm.rollback();
>                   // NO XASession? then manually rollback.
>                   // This is not so good but
>                   // it's the best we can do if we have no XASession.
>                   if (xaSession == null && serverSessionPool.isTransacted())
>                   {
>                      session.rollback();
>                   }
>                }
>                else if (trans.getStatus() == Status.STATUS_ACTIVE)
>                {
>                   // Commit tx
>                   // This will happen if
>                   // a) everything goes well
>                   // b) app. exception was thrown
>                   if (trace)
>                      log.trace(StdServerSession.this + " commiting the JMS transaction tx=" + trans);
>                   tm.commit();
>                   // NO XASession? then manually commit.  This is not so good but
>                   // it's the best we can do if we have no XASession.
>                   if (xaSession == null && serverSessionPool.isTransacted())
>                   {
>                      session.commit();
>                   }
>                }
> needs an extra branch:
>                else
>                {
>                   if (trace)
>                      log.trace(StdServerSession.this + " transaction already ended tx=" + trans);
>                   // spend the thread association
>                   tm.suspend();
>                   // NO XASession? then manually rollback.
>                   // This is not so good but
>                   // it's the best we can do if we have no XASession.
>                   if (xaSession == null && serverSessionPool.isTransacted())
>                   {
>                      session.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

        


From jira-events at jboss.com  Fri Sep 15 09:42:36 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 15 Sep 2006 09:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3483) The javadoc
 relating to StdServerSessionPool pooling parameters is wrong
In-Reply-To: <33330695.1154959692644.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3968004.1158327756688.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3483?page=all ]

Weston Price resolved JBAS-3483.
--------------------------------

    Resolution: Done

Updated JavaDoc to be more accurate for StdServerSessionPool parameters. 

> The javadoc relating to StdServerSessionPool pooling parameters is wrong
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3483
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3483
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The javadoc in the StdServerSessionPool constructor is misleading.
> It refers to the pool parameters controlling the number of sessions when it
> primarily controls the number of threads. Only the MaxPoolSize controls the number of sessions
> which are created at pool construction time.
> This WIKI page has it correct:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMDB

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:50:40 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 15 Sep 2006 09:50:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1040) Enhancements to
	DnD
Message-ID: <26504714.1158328240036.JavaMail.jira@cloud.prod.atl2.jboss.com>

Enhancements to DnD
-------------------

                 Key: JBPORTAL-1040
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1040
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


1. fix ordering to insert at the bottom-most area (after the last portlet).
2. dotted line cleanup.. 
    a. Either default to a simple insertion line, or
    b. try to simulate netvibes behaviour, of moving all below windows down and showing a highlighted target area.
3. cleanup messy and ill-performant code. (StringBuffers are your friend)
4. title bars, only, should be clickable for dragging.
5. Cursor should change to *something* when over a draggable region (before clicking).


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:12:37 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Fri, 15 Sep 2006 10:12:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-138) trailblazer demo has
 problems in some locales
Message-ID: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>

trailblazer demo has problems in some locales
---------------------------------------------

                 Key: JBESB-138
                 URL: http://jira.jboss.com/jira/browse/JBESB-138
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Examples
    Affects Versions: 4.0 Beta 1
            Reporter: Kurt Stam
         Assigned To: Kurt Stam
         Attachments: patch.txt

There a re parsing problems when converting a string (1000,00) to Double.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:12:37 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Fri, 15 Sep 2006 10:12:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-138) trailblazer demo has
 problems in some locales
In-Reply-To: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6626951.1158329557498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-138?page=all ]

Kurt Stam updated JBESB-138:
----------------------------

    Attachment: patch.txt

Patch to remove the cents in the formatting.

> trailblazer demo has problems in some locales
> ---------------------------------------------
>
>                 Key: JBESB-138
>                 URL: http://jira.jboss.com/jira/browse/JBESB-138
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Kurt Stam
>         Attachments: patch.txt
>
>
> There a re parsing problems when converting a string (1000,00) to Double.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:18:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 15 Sep 2006 10:18:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10209380.1158329927308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Fix Version/s: 1.4.0.SP2

Yep.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:36:36 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 15 Sep 2006 10:36:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
Message-ID: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>

Increase ClusterPartition buffers to support farming of large files
-------------------------------------------------------------------

                 Key: JBAS-3659
                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA


The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.

We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:57:39 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 10:57:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23865219.1158332259665.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-320?page=all ]

Bela Ban reassigned JGRP-320:
-----------------------------

    Assignee: Scott Marlow  (was: Bela Ban)

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Scott Marlow
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:26:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 15 Sep 2006 11:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-119) Parameter loading
 doesn't check for XML validity
In-Reply-To: <7780536.1154950212823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11193414.1158334002660.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-119?page=all ]

Mark Little reassigned JBESB-119:
---------------------------------

    Assignee: David DeGroff  (was: Esteban Schifman)

> Parameter loading doesn't check for XML validity
> ------------------------------------------------
>
>                 Key: JBESB-119
>                 URL: http://jira.jboss.com/jira/browse/JBESB-119
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Critical
>             Fix For: 4.0
>
>
> The current ParamRepository approach has a File implementation. It all appears to work on Strings (with the comments indicating how the strings should be formatted for structured attributes). However, some user classes assume the String is XML. Parameters should be provided to application classes through name/value pairs. How those pairs are loaded into the system (XML, strings, file, etc.) should be hidden.
> We also need an ESB schema.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:26:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 15 Sep 2006 11:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-122) Schema needed
In-Reply-To: <17213696.1154955972421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9607170.1158334002887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-122?page=all ]

Mark Little reassigned JBESB-122:
---------------------------------

    Assignee: David DeGroff  (was: Esteban Schifman)

> Schema needed
> -------------
>
>                 Key: JBESB-122
>                 URL: http://jira.jboss.com/jira/browse/JBESB-122
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Critical
>             Fix For: 4.0
>
>
> XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:36:37 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Fri, 15 Sep 2006 11:36:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8016852.1158334597813.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343386 ] 
            
Max Andersen commented on JBIDE-354:
------------------------------------

damn - would be great if we soon could get mail notifications to work for these jira updates ;)

in any case, i like the new one mostly because it is more vibrant...the red color.

And looking at that i got the idea...

What about making the moon red(ish) instead ? (maybe also on the main logo ?)

So it won't be the sun that is "shining" but our red moon ?



> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:50:38 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:50:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14164997.1158335438646.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic updated JBREM-596:
----------------------------------

        Summary: Lease stops working if the First Client using the same Locator is closed  (was: Lease doesn't work if client has two connections opened when using callbacks)
    Description: 
If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)

Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.


Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

  was:
If you have two connections, one of them is using CallBack the Lease is just stopped.

I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.

Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.

You can look at cruisecontrol results at this URL:

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html

and

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html


I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.



Here is the code:


	   public void testSimplestDurableSubscription() throws Exception
	   {
	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
	      
	      Connection conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();

	      Connection conn2 = cf.createConnection();
	      conn2.setClientID("client2");
	      conn2.start();

	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);

	      MessageProducer prod = s.createProducer(topic);
	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);

	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");

	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
	      
	      
	      for (int i=0;i<10;i++)
	      {
	    	  prod.send(s.createTextMessage("k"+i));
	      }
	      s.commit();

	      conn.close();
	      conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();
	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      durable = s.createDurableSubscriber(topic, "subs1");

	      for (int i=0;i<2;i++)
	      {
	    	  TextMessage tm = (TextMessage)durable.receive(1000);
	    	  assertNotNull(tm);
	    	  s.commit();
	    	  System.out.println(tm.getText());
	    	  assertEquals("k" + i, tm.getText());
	      }
	      
	      //conn.close();-- do not remote this comment. It was meant to not close the connection

	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
	   }



> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:52:37 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:52:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31476201.1158335557170.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343388 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

I have updated org.jboss.test.remoting.lease.socket.multiple.SocketLeaseTestClient to have the appropriate testing scenario

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:52:37 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:52:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15809897.1158335557330.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343389 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

We would need this fix on a 2.0.1.GA (or having a snapsho we could use on JMS)

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:56:38 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Fri, 15 Sep 2006 11:56:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12184490.1158335798388.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Stan Silvert updated JBAS-3554:
-------------------------------

    Priority: Critical  (was: Major)

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:58:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:58:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24169465.1158335915571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Assignee: Tom  Elrod  (was: Clebert Suconic)

Tom, this is a remoting but (the same one associated with this issue).


> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Fri Sep 15 12:00:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 12:00:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9029169.1158336035840.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic updated JBREM-596:
----------------------------------

    Comment: was deleted

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:00:36 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 12:00:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13521488.1158336036011.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343391 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

We would need this fix on a 2.0.1.GA (or having a snapshot we could use on Messaging)

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:34:36 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 15 Sep 2006 12:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1289887.1158338076513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Ryan Campbell reassigned JBAS-3650:
-----------------------------------

    Assignee: Prabhat Jha  (was: JBoss QA Lead)

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Prabhat Jha
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:34:36 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 15 Sep 2006 12:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28797539.1158338076664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Ryan Campbell updated JBAS-3650:
--------------------------------

    Due Date: 18/Sep/06

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Prabhat Jha
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:42:35 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 12:42:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-313) MultiplexerTests
 don't work with TCP configuration
In-Reply-To: <15805211.1158066153671.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29081274.1158338555209.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-313?page=all ]

Bela Ban resolved JGRP-313.
---------------------------

    Resolution: Done

> MultiplexerTests don't work with TCP configuration
> --------------------------------------------------
>
>                 Key: JGRP-313
>                 URL: http://jira.jboss.com/jira/browse/JGRP-313
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> UDP works 100%, however, some of the tests fail with a TCP configuration

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 13:00:36 2006
From: jira-events at jboss.com (Scott Marlow (JIRA))
Date: Fri, 15 Sep 2006 13:00:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27754779.1158339636995.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-320?page=comments#action_12343392 ] 
            
Scott Marlow commented on JGRP-320:
-----------------------------------

ConnectionTableNIO fix has been checked in.

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Scott Marlow
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 13:48:38 2006
From: jira-events at jboss.com (Jaroslaw Kijanowski (JIRA))
Date: Fri, 15 Sep 2006 13:48:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3660) Error starting up
 jaspi config on jboss-head testsuite module
Message-ID: <27348819.1158342518259.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error starting up jaspi config on jboss-head testsuite module
-------------------------------------------------------------

                 Key: JBAS-3660
                 URL: http://jira.jboss.com/jira/browse/JBAS-3660
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Jaroslaw Kijanowski
         Assigned To: Anil Saldhana
             Fix For: JBossAS-5.0.0.Beta


The testsuite fails while starting the "jaspi" instance in jbossas beta 5:
tests.log:
***************************
tests-security-jaspi-unit:
     [echo] creating jaspi config
     [copy] Copying 153 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
     [echo] Overwriting config descriptors
     [copy] Copying 2 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
[server:start] Starting server "jaspi" with command: 
[server:start] /opt/jrockit-jdk1.5.0_06/bin/java -cp /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/bin/run.jar:/opt/jrockit-jdk1.5.0_06/lib/tools.jar  org.jboss.Main -c jaspi -b localhost 
BUILD FAILED
/services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:827: The following error occurred while executing this line:
/services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:2414: Error starting server "jaspi": Server failed to start; see logs.
**************************
The server.log contains this:
**************************
11:25:01,556 ERROR [AbstractKernelController] Error installing to Configured: name=jboss.web:service=WebServer state=Instantiated mode=Manual requiredState=Configured
org.jboss.deployment.DeploymentException: No Attribute found with name: AuthorizationManagerService for jboss.web:service=WebServer
        at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java: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

        


From jira-events at jboss.com  Fri Sep 15 14:06:37 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Fri, 15 Sep 2006 14:06:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-300) move()
Message-ID: <24373359.1158343597332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-300?page=all ]

Manik Surtani closed JBCACHE-300.
---------------------------------

    Resolution: Done

> move()
> ------
>
>                 Key: JBCACHE-300
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-300
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Moves an entire subtree under a different subtree

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 14:06:37 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Fri, 15 Sep 2006 14:06:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-254) Provide an
 efficient way to relocate a child Node
Message-ID: <24588010.1158343597467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-254?page=all ]

Manik Surtani closed JBCACHE-254.
---------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.1.0)
       Resolution: Done

Fixed this in 2.0.0 - a single move() impl.

> Provide an efficient way to relocate a child Node
> -------------------------------------------------
>
>                 Key: JBCACHE-254
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-254
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> Can TreeCache provide an efficient to re-locate a child Node say from parent A to parent B? The only problem I see is the associated fqn name. I may need this feature in TreeCacheAop.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 14:34:43 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Fri, 15 Sep 2006 14:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12389352.1158345283682.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343394 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

I made a third version that replaced the black moon with a red one as per Max's feedback. The sun is still shining, but the moon blocks the view, hence the rays around it. :)


http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm


16 x 16
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside_v3.gif

32 x 32
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside_v3.gif

They can be seen in action here:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_jbosside_page_v3.gif

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 14:36:34 2006
From: jira-events at jboss.com (Adam Brod (JIRA))
Date: Fri, 15 Sep 2006 14:36:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-354) Better support for
 JSF-style managed properties
Message-ID: <28874974.1158345394933.JavaMail.jira@cloud.prod.atl2.jboss.com>

Better support for JSF-style managed properties
-----------------------------------------------

                 Key: JBSEAM-354
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-354
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: JSF
    Affects Versions: 1.0.1
            Reporter: Adam Brod
            Priority: Minor


The @In annotation should support the same syntax as JSF managed properties.  That means that If I have this annotation in my Bean:

@In("#{param.fileId}")
Long fileId

Seam should automatically inject that property performing the correct JSF conversion.  In Shale I can do that with the @Value or @Property annotation.  It is very confusing that I need a specialized annotation that doesn't support the EL just for request parameters when JSF doesn't make that distinction.

I believe this could be implemented with a few small changes to Component.  Inside Component.getInstanceToInject(...), the logic which first checks to see if the name is an EL (line 1358 in Seam 1.0.1) could also check to see if the expression begins with "#{param.", if so, then it can call to Component.convertRequestParameter(...) to convert the type.

This is a small change to Component, but it makes the overall Seam API more consistent.  It allows me to use the EL anywhere I want.  I don't have to worry about using @In or @RequestParameter, I just use the EL.



-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:04:37 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:04:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3661) LdapExtLoginModule
 should detect communication failures midstream
Message-ID: <21180085.1158350677198.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule should detect communication failures midstream
-----------------------------------------------------------------

                 Key: JBAS-3661
                 URL: http://jira.jboss.com/jira/browse/JBAS-3661
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Scott M Stark


There is a possibility of the context going stale due to communication exceptions with the ldap server when dealing with references etc.  It may be useful for the LdapExtLoginModule to implement the:
http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/UnsolicitedNotificationListener.html

such that it can do graceful processing.


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:06:35 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-5) Integrate OpenDS in
 HEAD testsuite
In-Reply-To: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17565281.1158350795839.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-5?page=all ]

Anil Saldhana closed SECURITY-5.
--------------------------------

    Fix Version/s: 2.0
       Resolution: Done

asaldhana~/jboss-5.0/jboss-head/testsuite>ant tests-ldap
Buildfile: build.xml
Overriding previous definition of reference to jboss.test.classpath

tests-ldap:
     [echo] creating opends config
     [echo] Overwriting config descriptors
     [copy] Copying 20 files to C:\cygwin\home\asaldhana\jboss-5.0\jboss-head\bu
ild\output\jboss-5.0.0.Beta\server\opends
[server:start] Starting server "opends" with command:
[server:start] C:\Java\jdk1.5.0_04\bin\java -cp C:\cygwin\home\asaldhana\jboss-5
.0\jboss-head\build\output\jboss-5.0.0.Beta\bin\run.jar;c:\java\jdk1.5.0_04\lib\
tools.jar   org.jboss.Main -c opends -b localhost
     [echo] Starting patternset=ldap.includes config=opends
    [junit] Running org.jboss.test.security.test.opends.LdapBasicUnitTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.922 sec
[server:stop] Shutting down server: opends

BUILD SUCCESSFUL
Total time: 31 seconds

> Integrate OpenDS in HEAD testsuite
> ----------------------------------
>
>                 Key: SECURITY-5
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule
> Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.
> My prelim testing details:
> ====================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
> [12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
>  Directory Server 0.1-build007 starting up."
> [12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
> database backend containing 1 entries has started."
> [12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
> msg="Access control has been disabled."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
> rectory Server has started successfully."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
> rectory Server has sent an alert notification generated by class org.opends.serv
> er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
> ert ID 458887):  The Directory Server has started successfully.."
> ================================================================================
> =============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
> -D "cn=Directory Manager" -w password -a -f a.ldif
> Processing ADD request for dc=jboss,dc=org.
> ADD operation successful for DN dc=jboss,dc=org.
> Processing ADD request for ou=People,dc=jboss,dc=org.
> ADD operation successful for DN ou=People,dc=jboss,dc=org.
> Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.
> ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.
> Processing ADD request for ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ===============================================================================
> ==============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
>  -b "dc=jboss,dc=org" -s sub "objectclass=*"
> dn: dc=jboss,dc=org
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o: JBoss
> dc: jboss
> dn: ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: person
> objectClass: uidObject
> userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
> cn: Java Duke
> sn: Duke
> uid: jduke
> =====================================================================================
> The application policy:
> <application-policy name = "jmx-console">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
>                           flag="required">
>                 <module-option name="java.naming.factory.initial"> 
>                     com.sun.jndi.ldap.LdapCtxFactory
>                     </module-option>
>                 <module-option name="java.naming.provider.url">
>                     ldap://localhost:389/
>                 </module-option>
>                 <module-option name="java.naming.security.authentication">
>                     simple
>                 </module-option>
>                 <module-option name="principalDNPrefix">uid=</module-option>                    
>                 <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
>                 <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
>                 <module-option name="uidAttributeID">member</module-option>
>                 <module-option name="matchOnUserDN">true</module-option>
>                 <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false</module-option>
>                 <module-option name="searchTimeLimit">5000</module-option>
>                 <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
>             </login-module>
>         </authentication>
>     </application-policy>

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:06:35 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-8) LdapExtLoginModule
 should detect communication failures midstream
Message-ID: <1391642.1158350795955.JavaMail.jira@cloud.prod.atl2.jboss.com>

 LdapExtLoginModule should detect communication failures midstream
------------------------------------------------------------------

                 Key: SECURITY-8
                 URL: http://jira.jboss.com/jira/browse/SECURITY-8
             Project: JBoss Security
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0


http://jira.jboss.com/jira/browse/JBAS-3661

There is a possibility of the context going stale due to communication exceptions with the ldap server when dealing with references etc. It may be useful for the LdapExtLoginModule to implement the:
http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/UnsolicitedNotificationListener.html

such that it can do graceful processing. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:06:36 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:06:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3661) LdapExtLoginModule
 should detect communication failures midstream
In-Reply-To: <21180085.1158350677198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27531794.1158350796109.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3661?page=all ]

Anil Saldhana updated JBAS-3661:
--------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> LdapExtLoginModule should detect communication failures midstream
> -----------------------------------------------------------------
>
>                 Key: JBAS-3661
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3661
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> There is a possibility of the context going stale due to communication exceptions with the ldap server when dealing with references etc.  It may be useful for the LdapExtLoginModule to implement the:
> http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/UnsolicitedNotificationListener.html
> such that it can do graceful processing.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:08:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 16:08:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7927084.1158350917175.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-320?page=all ]

Bela Ban resolved JGRP-320.
---------------------------

    Resolution: Done

Scott changed ConnectionTableNIO, now those tests work too

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Scott Marlow
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:08:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 16:08:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-321)
 CloseTest.testShutdown() fails with -Dconfig=tcp.xml
Message-ID: <20644013.1158350917305.JavaMail.jira@cloud.prod.atl2.jboss.com>

CloseTest.testShutdown() fails with -Dconfig=tcp.xml
----------------------------------------------------

                 Key: JGRP-321
                 URL: http://jira.jboss.com/jira/browse/JGRP-321
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4




-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:02:35 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Fri, 15 Sep 2006 17:02:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-367) Eclipse dependancy
 versions are too strict/narrow
Message-ID: <5909308.1158354155429.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eclipse dependancy versions are too strict/narrow
-------------------------------------------------

                 Key: JBIDE-367
                 URL: http://jira.jboss.com/jira/browse/JBIDE-367
             Project: JBoss IDE
          Issue Type: Bug
          Components: Build System (Releng)
    Affects Versions: 2.0.0.Beta1
            Reporter: Darryl Miles
         Assigned To: Marshall Culpepper
            Priority: Minor


Release versioning is too strict and does not allow compatible newer versions of WTP/EMFXSD to be installed.


Related URLs:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87879&postdays=0&postorder=asc&start=10
http://opensource.atlassian.com/projects/hibernate/browse/HBX-709


This is the error list for after I upgraded WTP to the current I-build for this week.  Note I have all of these features/plugins installed but slightly newer versions of them the problem is the features.xml for the JbossIDE product is too strict insisting in the exact version it was built with.  When it should really make that the oldest version it will accept.

Plug-in "org.eclipse.wst.xml.core" version "1.1.0.v200606142000" referenced by this feature is missing.
Plug-in "org.eclipse.wst.xml.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.sse.core" version "1.1.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.sse.ui" version "1.0.101.v200606191900" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.uriresolver" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.validation" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.frameworks" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.ui" version "1.1.0.v200606142122" referenced by this feature is missing.
Plug-in "org.eclipse.emf.ecore" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.emf.ecore.xmi" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.jst.jsp.core" version "1.1.0.v200606191945" referenced by this feature is missing.
Plug-in "org.eclipse.jst.jsp.ui" version "1.1.0.v200606191945" referenced by this feature is missing.
Plug-in "org.eclipse.wst.html.core" version "1.1.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.html.standard.dtds" version "1.0.0" referenced by this feature is missing.
Plug-in "org.eclipse.wst.html.ui" version "1.0.100.v200606191945" referenced by this feature is missing.
Plug-in "org.eclipse.wst.css.core" version "1.1.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.css.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.javascript.core" version "1.0.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.javascript.ui" version "1.0.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.environment" version "1.0.100.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.emf.common" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.emf" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.emfworkbench.integration" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.emf.edit" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.xsd" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.project.facet.core" version "1.1.0.v200606130645" referenced by this feature is missing.


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:18:33 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 17:18:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-5) Integrate OpenDS
 in HEAD testsuite
In-Reply-To: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31950215.1158355113618.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/SECURITY-5?page=comments#action_12343398 ] 
            
Anil Saldhana commented on SECURITY-5:
--------------------------------------

There is a XMBean service that starts/stops OpenDS inside a JBoss instance.
org.jboss.test.security.test.opends.OpenDSService


Also, there is a server configuration called as "opends" that sets up the opends config structure under:
jboss_instance/server/opends/conf/opends


Some DS log files are found under jboss_instance/server/opends/conf/opends/logs (access,errors,debug)

Also take notice of a OpenDS utility class in the test suite that can be used to add ldifs, delete DN, search etc.
org.jboss.test.security.test.opends.OpenDSUtil

> Integrate OpenDS in HEAD testsuite
> ----------------------------------
>
>                 Key: SECURITY-5
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule
> Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.
> My prelim testing details:
> ====================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
> [12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
>  Directory Server 0.1-build007 starting up."
> [12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
> database backend containing 1 entries has started."
> [12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
> msg="Access control has been disabled."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
> rectory Server has started successfully."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
> rectory Server has sent an alert notification generated by class org.opends.serv
> er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
> ert ID 458887):  The Directory Server has started successfully.."
> ================================================================================
> =============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
> -D "cn=Directory Manager" -w password -a -f a.ldif
> Processing ADD request for dc=jboss,dc=org.
> ADD operation successful for DN dc=jboss,dc=org.
> Processing ADD request for ou=People,dc=jboss,dc=org.
> ADD operation successful for DN ou=People,dc=jboss,dc=org.
> Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.
> ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.
> Processing ADD request for ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ===============================================================================
> ==============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
>  -b "dc=jboss,dc=org" -s sub "objectclass=*"
> dn: dc=jboss,dc=org
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o: JBoss
> dc: jboss
> dn: ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: person
> objectClass: uidObject
> userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
> cn: Java Duke
> sn: Duke
> uid: jduke
> =====================================================================================
> The application policy:
> <application-policy name = "jmx-console">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
>                           flag="required">
>                 <module-option name="java.naming.factory.initial"> 
>                     com.sun.jndi.ldap.LdapCtxFactory
>                     </module-option>
>                 <module-option name="java.naming.provider.url">
>                     ldap://localhost:389/
>                 </module-option>
>                 <module-option name="java.naming.security.authentication">
>                     simple
>                 </module-option>
>                 <module-option name="principalDNPrefix">uid=</module-option>                    
>                 <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
>                 <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
>                 <module-option name="uidAttributeID">member</module-option>
>                 <module-option name="matchOnUserDN">true</module-option>
>                 <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false</module-option>
>                 <module-option name="searchTimeLimit">5000</module-option>
>                 <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
>             </login-module>
>         </authentication>
>     </application-policy>

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:30:37 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:30:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-408) Queue binds in
 jndi but cannot be looked up
Message-ID: <7618458.1158355837466.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=all ]

Clebert Suconic updated JBMESSAGING-408:
----------------------------------------

    Attachment: test.tar.gz

> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:38:34 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Fri, 15 Sep 2006 17:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16809247.1158356314781.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=all ]

Boleslaw Dawidowicz updated JBPORTAL-1034:
------------------------------------------

    Description: 
- define architecture, goals and roadmap for portal - ldap integration
- prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration


  was:prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration


> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>          Time Spent: 1 week, 2 hours
>
> - define architecture, goals and roadmap for portal - ldap integration
> - prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:40:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-408) Queue binds
 in jndi but cannot be looked up
Message-ID: <32966760.1158356434258.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=all ]

Clebert Suconic resolved JBMESSAGING-408.
-----------------------------------------

    Fix Version/s:     (was: 1.0.1.CR5)
       Resolution: Cannot Reproduce Bug

I suspect you have a configuration issue with your security system.


I have deployed your application, and never had any exceptions. (I had to place jboss-messaging.jar into /lib though).

> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:40:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-408) Queue binds in
 jndi but cannot be looked up
Message-ID: <4499909.1158356434445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=all ]

Clebert Suconic closed JBMESSAGING-408.
---------------------------------------


> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:40:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-408) Queue binds
 in jndi but cannot be looked up
Message-ID: <20203991.1158356434612.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=comments#action_12343401 ] 
            
Clebert Suconic commented on JBMESSAGING-408:
---------------------------------------------

You will find test.tar.gz with my package (which has a small build.xml) and few changes I have made.

> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 18:26:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 18:26:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <24986188.1158359194768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Clebert Suconic updated JBMESSAGING-432:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90803

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 19:14:39 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Fri, 15 Sep 2006 19:14:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-367) Eclipse dependancy
 versions are too strict/narrow
In-Reply-To: <5909308.1158354155429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23425467.1158362079045.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-367?page=comments#action_12343408 ] 
            
Max Andersen commented on JBIDE-367:
------------------------------------

is this against the nightly build or the release ?



> Eclipse dependancy versions are too strict/narrow
> -------------------------------------------------
>
>                 Key: JBIDE-367
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-367
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Build System (Releng)
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Marshall Culpepper
>            Priority: Minor
>
> Release versioning is too strict and does not allow compatible newer versions of WTP/EMFXSD to be installed.
> Related URLs:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87879&postdays=0&postorder=asc&start=10
> http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> This is the error list for after I upgraded WTP to the current I-build for this week.  Note I have all of these features/plugins installed but slightly newer versions of them the problem is the features.xml for the JbossIDE product is too strict insisting in the exact version it was built with.  When it should really make that the oldest version it will accept.
> Plug-in "org.eclipse.wst.xml.core" version "1.1.0.v200606142000" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.xml.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.ui" version "1.0.101.v200606191900" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.uriresolver" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.validation" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.frameworks" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.ui" version "1.1.0.v200606142122" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore.xmi" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.core" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.ui" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.standard.dtds" version "1.0.0" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.ui" version "1.0.100.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.core" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.ui" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.environment" version "1.0.100.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.common" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emf" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emfworkbench.integration" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.edit" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.xsd" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.project.facet.core" version "1.1.0.v200606130645" referenced by this feature is missing.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 19:26:34 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 15 Sep 2006 19:26:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1041) WSRP's
 processing of fragments leaves the fragment in incoherent state
Message-ID: <22480412.1158362794036.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP's processing of fragments leaves the fragment in incoherent state
----------------------------------------------------------------------

                 Key: JBPORTAL-1041
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1041
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1


We currently only add rewriting tokens for id attributes. However, doing so, we fail to also add the tokens when the id are used (in javascript, for example).

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 20:58:33 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Fri, 15 Sep 2006 20:58:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-367) Eclipse dependancy
 versions are too strict/narrow
In-Reply-To: <5909308.1158354155429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5007313.1158368313361.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-367?page=comments#action_12343410 ] 
            
Darryl Miles commented on JBIDE-367:
------------------------------------

The Release, but I've got the Nightly built so I'll give that a go tomorrow.

> Eclipse dependancy versions are too strict/narrow
> -------------------------------------------------
>
>                 Key: JBIDE-367
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-367
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Build System (Releng)
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Marshall Culpepper
>            Priority: Minor
>
> Release versioning is too strict and does not allow compatible newer versions of WTP/EMFXSD to be installed.
> Related URLs:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87879&postdays=0&postorder=asc&start=10
> http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> This is the error list for after I upgraded WTP to the current I-build for this week.  Note I have all of these features/plugins installed but slightly newer versions of them the problem is the features.xml for the JbossIDE product is too strict insisting in the exact version it was built with.  When it should really make that the oldest version it will accept.
> Plug-in "org.eclipse.wst.xml.core" version "1.1.0.v200606142000" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.xml.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.ui" version "1.0.101.v200606191900" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.uriresolver" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.validation" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.frameworks" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.ui" version "1.1.0.v200606142122" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore.xmi" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.core" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.ui" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.standard.dtds" version "1.0.0" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.ui" version "1.0.100.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.core" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.ui" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.environment" version "1.0.100.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.common" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emf" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emfworkbench.integration" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.edit" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.xsd" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.project.facet.core" version "1.1.0.v200606130645" referenced by this feature is missing.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 21:34:33 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 21:34:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3660) Error starting up
 jaspi config on jboss-head testsuite module
In-Reply-To: <27348819.1158342518259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7754828.1158370473957.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3660?page=all ]

Anil Saldhana closed JBAS-3660.
-------------------------------

    Resolution: Done

> Error starting up jaspi config on jboss-head testsuite module
> -------------------------------------------------------------
>
>                 Key: JBAS-3660
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3660
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Jaroslaw Kijanowski
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The testsuite fails while starting the "jaspi" instance in jbossas beta 5:
> tests.log:
> ***************************
> tests-security-jaspi-unit:
>      [echo] creating jaspi config
>      [copy] Copying 153 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
>      [echo] Overwriting config descriptors
>      [copy] Copying 2 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
> [server:start] Starting server "jaspi" with command: 
> [server:start] /opt/jrockit-jdk1.5.0_06/bin/java -cp /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/bin/run.jar:/opt/jrockit-jdk1.5.0_06/lib/tools.jar  org.jboss.Main -c jaspi -b localhost 
> BUILD FAILED
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:827: The following error occurred while executing this line:
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:2414: Error starting server "jaspi": Server failed to start; see logs.
> **************************
> The server.log contains this:
> **************************
> 11:25:01,556 ERROR [AbstractKernelController] Error installing to Configured: name=jboss.web:service=WebServer state=Instantiated mode=Manual requiredState=Configured
> org.jboss.deployment.DeploymentException: No Attribute found with name: AuthorizationManagerService for jboss.web:service=WebServer
>         at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java: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

        


From jira-events at jboss.com  Fri Sep 15 21:34:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 21:34:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3660) Error starting up
 jaspi config on jboss-head testsuite module
In-Reply-To: <27348819.1158342518259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30047668.1158370474136.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3660?page=comments#action_12343411 ] 
            
Anil Saldhana commented on JBAS-3660:
-------------------------------------

Should be fixed now.

> Error starting up jaspi config on jboss-head testsuite module
> -------------------------------------------------------------
>
>                 Key: JBAS-3660
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3660
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Jaroslaw Kijanowski
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The testsuite fails while starting the "jaspi" instance in jbossas beta 5:
> tests.log:
> ***************************
> tests-security-jaspi-unit:
>      [echo] creating jaspi config
>      [copy] Copying 153 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
>      [echo] Overwriting config descriptors
>      [copy] Copying 2 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
> [server:start] Starting server "jaspi" with command: 
> [server:start] /opt/jrockit-jdk1.5.0_06/bin/java -cp /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/bin/run.jar:/opt/jrockit-jdk1.5.0_06/lib/tools.jar  org.jboss.Main -c jaspi -b localhost 
> BUILD FAILED
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:827: The following error occurred while executing this line:
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:2414: Error starting server "jaspi": Server failed to start; see logs.
> **************************
> The server.log contains this:
> **************************
> 11:25:01,556 ERROR [AbstractKernelController] Error installing to Configured: name=jboss.web:service=WebServer state=Instantiated mode=Manual requiredState=Configured
> org.jboss.deployment.DeploymentException: No Attribute found with name: AuthorizationManagerService for jboss.web:service=WebServer
>         at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java: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

        


From jira-events at jboss.com  Sat Sep 16 01:20:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 01:20:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-770) PojoCache to
 support non-serializable and no-aspectized POJO
Message-ID: <13802366.1158384047408.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to support non-serializable and no-aspectized POJO
------------------------------------------------------------

                 Key: JBCACHE-770
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-770
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: PojoCache


Currently in 2.0, we have to drop the support for the non-serializable and non-aspectized POJO, that is, a POJO that is neither implements Serializable or instrumented.



-- 
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

        


From jira-events at jboss.com  Sat Sep 16 01:32:47 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 16 Sep 2006 01:32:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1040) Enhancements
	to DnD
In-Reply-To: <26504714.1158328240036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16545980.1158384767381.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1040?page=comments#action_12343412 ] 
            
Roy Russo commented on JBPORTAL-1040:
-------------------------------------

1-3, complete. 

4 & 5 are related. Suggested fix is, when an emptyrenderer window is encountered make entire area draggable. For other renderers, use title bar.

> Enhancements to DnD
> -------------------
>
>                 Key: JBPORTAL-1040
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1040
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> 1. fix ordering to insert at the bottom-most area (after the last portlet).
> 2. dotted line cleanup.. 
>     a. Either default to a simple insertion line, or
>     b. try to simulate netvibes behaviour, of moving all below windows down and showing a highlighted target area.
> 3. cleanup messy and ill-performant code. (StringBuffers are your friend)
> 4. title bars, only, should be clickable for dragging.
> 5. Cursor should change to *something* when over a draggable region (before clicking).

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 07:54:47 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Sat, 16 Sep 2006 07:54:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-483) Open Decision
 Table API to allow custom RuleSheetListeners
In-Reply-To: <21379798.1157959843818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3470210.1158407687595.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-483?page=all ]

Steven Williams resolved JBRULES-483.
-------------------------------------

    Fix Version/s: 3.0.5
       Resolution: Done

Opened up API and added example custom listener.

> Open Decision Table API to allow custom RuleSheetListeners
> ----------------------------------------------------------
>
>                 Key: JBRULES-483
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-483
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Steven Williams
>         Assigned To: Mark Proctor
>             Fix For: 3.0.5
>
>         Attachments: Rule.java, RuleSheetListener.java, SpreadsheetCompiler.java
>
>
> I have a need for a different format for my decision tables - basically instead of the current format with one row per rule with conditions across the top I need to support a matrix-like structure where both the horizontal and the vertical axes represent conditions and the intersection represents the action. In order to do this I created my own MatrixRuleSheetListener inheriting from RuleSheetListener and overriding certain methods. This all works fine however I had to hack the drools code a little to allow me to do it. I was wondering if it would be possible to open up the API to allow this.
> Specifically:
> 1. add method to org.drools.decisiontable.parser.RuleSheetListener
>     protected void addRule(Rule rule)
>     {
>         this._ruleList.add(rule);
>     }
> 2. add empty protected methods preInitRuleTable(row, column, value) and postInitRuleTable(row, column, value, rule) to org.drools.decisiontable.parser.RuleSheetListener which are called from the start and end of the initRuleTable method.
> 3. Add agendaGroup property to org.drools.decisiontable.model.Rule
> 4. Add a new method compile(InputStream, InputType, RuleSheetListener) to org.drools.decisiontable.SpreadsheetCompiler
> I have attached these changes to this request.
> Steve

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 11:12:47 2006
From: jira-events at jboss.com (=?UTF-8?Q?Ortwin_Gl=C3=BCck_=28JIRA=29?=)
Date: Sat, 16 Sep 2006 11:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-46) Javassist lazy
 proxy factoring not thread-safe
Message-ID: <18818166.1158419567580.JavaMail.jira@cloud.prod.atl2.jboss.com>

Javassist lazy proxy factoring not thread-safe
----------------------------------------------

                 Key: HIBERNATE-46
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-46
             Project: Hibernate
          Issue Type: Bug
         Environment: JBoss AS 4.0.4 with EJB 3-RC8
            Reporter: Ortwin Gl?ck
         Assigned To: Steve Ebersole


Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.

The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.

Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
s definition: test/BusinessOrganization_$$_javass
ist_272
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
        at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
JavassistLazyInitializer.java:79)
        ... 136 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
e class definition: ch/logobject/mlogistics/om/resource/BusinessOrganization_$$_
javassist_272
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
        ... 137 more
Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
        at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
        ... 138 more

-- 
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

       



From jira-events at jboss.com  Sat Sep 16 11:14:47 2006
From: jira-events at jboss.com (=?UTF-8?Q?Ortwin_Gl=C3=BCck_=28JIRA=29?=)
Date: Sat, 16 Sep 2006 11:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (HIBERNATE-46) Javassist lazy
 proxy factoring not thread-safe
In-Reply-To: <18818166.1158419567580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22042126.1158419687477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/HIBERNATE-46?page=all ]

Ortwin Gl?ck updated HIBERNATE-46:
----------------------------------

    Description: 
Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.

The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.

Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
s definition: test/BusinessOrganization_$$_javass
ist_272
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
        at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
JavassistLazyInitializer.java:79)
        ... 136 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
e class definition: test/BusinessOrganization_$$_
javassist_272
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
        ... 137 more
Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
        at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
        ... 138 more

  was:
Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.

The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.

Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
s definition: test/BusinessOrganization_$$_javass
ist_272
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
        at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
JavassistLazyInitializer.java:79)
        ... 136 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
e class definition: ch/logobject/mlogistics/om/resource/BusinessOrganization_$$_
javassist_272
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
        ... 137 more
Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
        at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
        ... 138 more


> Javassist lazy proxy factoring not thread-safe
> ----------------------------------------------
>
>                 Key: HIBERNATE-46
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-46
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: JBoss AS 4.0.4 with EJB 3-RC8
>            Reporter: Ortwin Gl?ck
>         Assigned To: Steve Ebersole
>
> Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.
> The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.
> Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
> s definition: test/BusinessOrganization_$$_javass
> ist_272
>         at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
>         at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
> JavassistLazyInitializer.java:79)
>         ... 136 more
> Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
> e class definition: test/BusinessOrganization_$$_
> javassist_272
>         at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
>         at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
>         ... 137 more
> Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
>         at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
>         ... 138 more

-- 
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

       



From jira-events at jboss.com  Sat Sep 16 11:52:47 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Sat, 16 Sep 2006 11:52:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-707)
 TreeCacheProviderHook.isMinimalPutsEnabledByDefault() wrong
Message-ID: <30441832.1158421967437.JavaMail.jira@cloud.prod.atl2.jboss.com>

TreeCacheProviderHook.isMinimalPutsEnabledByDefault() wrong
-----------------------------------------------------------

                 Key: EJBTHREE-707
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-707
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Owen Taylor
            Priority: Minor


org.jboss.ejb3.entity.TreeCacheProviderHook.isMinimalPutsEnabledByDefault()  returns false,
which means "don't check to see if values are in the cache before inserting them again", but
that's a very bad setting for the TreeCache

 - It causes unnecessary replication between the nodes of a cluster
 - It tends to cause lock conflicts because the transaction putting data
   into the cache has to get a (briefly) get a write lock. There are hacky workarounds in the
   hibernate TreeCache code not to deadlock in this code, but you still get log spew.

The TreeCacheProvider provided with Hibernate (no JMX integration) returns true 
isMinimalPutsEnabledByDefault() as it should, so I think this is just an oversight.

You can of course easily work around the problem by setting the value explicitly in the
hibernate properties.


-- 
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

        


From jira-events at jboss.com  Sat Sep 16 12:46:47 2006
From: jira-events at jboss.com (degerhar (JIRA))
Date: Sat, 16 Sep 2006 12:46:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-665) @PostConstruct
 throws NPE when EntityManager is used
In-Reply-To: <24188502.1153922291327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10863356.1158425207783.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-665?page=comments#action_12343414 ] 
            
degerhar commented on EJBTHREE-665:
-----------------------------------

Hi.

I have the same problem with Mandriva 10.2, JBoss-4.0.4.GA

I have a Timer that execute some SQL every minute via an entity manager.
The method in which this happen is exposed in JMX.

When I execute the method from the jmx-console, the SQL is executed fine.
When the Timer fires to execute the method, I get the NPE:

It seems the root cause of the problem is at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)

java.lang.NullPointerException
at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)
at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:163)
at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:125)
at com.yannitech.security.jmx.UserService.expireSessions(UserService.java:219)
at com.yannitech.security.jmx.UserService.checkSessions(UserService.java:131)
at com.yannitech.security.jmx.UserService.handleNotification(UserService.java:123)
at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
at $Proxy217.handleNotification(Unknown Source)
at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:221)
at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:184)
at javax.management.timer.Timer.sendNotification(Timer.java:1295)
at javax.management.timer.Timer.notifyAlarmClock(Timer.java:1264)
at javax.management.timer.TimerAlarmClock.run(Timer.java:1347)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

Gerhard

> @PostConstruct throws NPE when EntityManager is used
> ----------------------------------------------------
>
>                 Key: EJBTHREE-665
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-665
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: Windows XP, JBoss 4.0.4.GA + EJB-3.0-RC8
>            Reporter: Steven Verze
>
> @PostConstruct method throws NPE when called on a stateless session bean.
> The method iteself accesses the enetity manager and tries create a query, the following exception is experienced:
> java.lang.RuntimeException: java.lang.NullPointerException
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:109)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:163)
> 	at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:125)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceBean.initialiseSpendCardQuery(SnapAccountSendProcessServiceBean.java:83)
> 	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.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:159)
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:105)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
> 	at $Proxy3.getBatchNumbers(Unknown Source)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceTest.testGetBatchNumbers(SnapAccountSendProcessServiceTest.java:57)
> 	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 junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Here is a the post construct method:
> @PostConstruct
>     void initialiseSpendCardQuery()
> 	{		
> 		StringBuilder sendCardQueryString = new StringBuilder();    	
> 		sendCardQueryString.append("SELECT c FROM Card AS c WHERE c.status = 'U' AND c.batchNumber IN (");
> 		 
> 		long[] batchNumbers = getBatchNumbers();
> 		for (int i = 0; i < batchNumbers.length; i++)
> 		{
> 		    sendCardQueryString.append("?").append(i);
> 			if (i+1 < batchNumbers.length)
> 			    sendCardQueryString.append(",");
> 		}
> 		sendCardQueryString.append(") AND c NOT IN (SELECT lc.sendCard FROM SendCardLock AS lc)");
> 		sendCardQuery = entityManager.createQuery(sendCardQueryString.toString());
> 		 
> 		for (int i = 0; i < batchNumbers.length; i++)
> 			sendCardQuery.setParameter(i, batchNumbers[i]);		
> 	}
> It happens when the entityManager is used.

-- 
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

        


From global888 at yahoo.com  Sun Sep 17 02:28:06 2006
From: global888 at yahoo.com (ªÔ³Õ¹Øª)
Date: Sun, 17 Sep 2006 02:28:06
Subject: [jboss-jira] =?iso-8859-1?q?Now!_=CD=B9=D2=A4=B5=A2=CD=A7=A4=D8?=
	=?iso-8859-1?q?=B3=C3=CD=E4=C1=E8=E4=B4=E9=E1=C5=E9=C7?=
Message-ID: <200609161928.k8GJRnI8026654@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060917/c2d7b880/attachment.html 

From jira-events at jboss.com  Sat Sep 16 19:34:48 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Sat, 16 Sep 2006 19:34:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2663141.1158449688561.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343416 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

I've done some more investigations and see that the first solution with separate contexts is the way to go. Why? Because isolation is needed between the applications.

With the implementation where the virtual-host/context-path information is bound to the Portal object then if I deploy my portal to http://portaltest.abrahamsson.com then I can access the default portal on http://portaltest.abrahamsson.com/portal/default/. Well, sort of since the portlets are rendered but images etc can't be loaded, since they are in a different web application context.

That is essentially the point, like the servlet container maintains different contexts to isolate different applications so does the portal server need to do. This turned out to work supprisingly well in the first approach I did, the rest of the app seams to be designed with multiple contexts in mind even if the model isn't.

What needs to be discussed is how it should be specified in the *-object.xml file which context a portal should be deployed to. I find that the most logical is that unless a parent ref is specified then it should be bound to the context created by the war. If the parent ref is empty (i.e. <parentref/>) then the portal is bound to the default context and if a specific parent is specified then the it is bound to that context. This is also consistent with how things have worked historically.

I've done some basic testing on letting the portals having different security domains which seams to work fine but needs further analysis, especially how it affects the cms.

Note that the ObjectNodes still form a tree, with the default context as root and the other contextes as children to it.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4-2.patch, jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 21:06:47 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 16 Sep 2006 21:06:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1040) Enhancements to
	DnD
In-Reply-To: <26504714.1158328240036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2354631.1158455207492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1040?page=all ]

Roy Russo resolved JBPORTAL-1040.
---------------------------------

    Resolution: Done

> Enhancements to DnD
> -------------------
>
>                 Key: JBPORTAL-1040
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1040
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> 1. fix ordering to insert at the bottom-most area (after the last portlet).
> 2. dotted line cleanup.. 
>     a. Either default to a simple insertion line, or
>     b. try to simulate netvibes behaviour, of moving all below windows down and showing a highlighted target area.
> 3. cleanup messy and ill-performant code. (StringBuffers are your friend)
> 4. title bars, only, should be clickable for dragging.
> 5. Cursor should change to *something* when over a draggable region (before clicking).

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 21:20:47 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 16 Sep 2006 21:20:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1042) Add AJAX request
	Javascript
Message-ID: <13107312.1158456047454.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add AJAX request Javascript
---------------------------

                 Key: JBPORTAL-1042
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1042
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


Add DOM walker and storing of original values, and try to supply this to backend:

- window id/window name
- source coordinates (region / index)
- destination coordinates (regin / index)



-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:00:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:00:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-685) Integration using
 the new Cache2.0 API and SPI
Message-ID: <5483479.1158462047510.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-685?page=all ]

Ben Wang resolved JBCACHE-685.
------------------------------

    Resolution: Done

> Integration using the new Cache2.0 API and SPI
> ----------------------------------------------
>
>                 Key: JBCACHE-685
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-685
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Currently, PojoCache 2.0 development is still using the old TreeCache API. It would be nice to migrate to 2.0 API when it is completed.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:00:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:00:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-584) Investigate use of
 lazy mapping for PojoCache
Message-ID: <3358098.1158462047621.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-584?page=all ]

Ben Wang updated JBCACHE-584:
-----------------------------

    Fix Version/s: PojoCache 2.1.0
                       (was: PojoCache 2.2.0)

> Investigate use of lazy mapping for PojoCache
> ---------------------------------------------
>
>                 Key: JBCACHE-584
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-584
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Recent perf test on PojoCache shows bottleneck is on the initial mapping of putObject causing numerous trips to the local cache store. To optimize it further, either the TreeCache local mode need to be enhanced. Or one solution to this is the use of lazy mapping of the pojo. For example, when putObject is called, pojo is not mapped. Instead, it is stored under a "Serialized" state (can use JBossSerialization if  pojo is not even Seriailizable) first. Then when the field is modified (detected from the CacheInterceptor), we will then map it lazily to the PojoCache store.
> The performance gain can be had, if 1) initial saving of mapping, 2) field update is only selected.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:02:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:02:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-450) Create a pure
 pojo-based eviction policy
Message-ID: <7406915.1158462167463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-450?page=all ]

Ben Wang updated JBCACHE-450:
-----------------------------

    Fix Version/s: 2.0.0
                       (was: PojoCache)

> Create a pure pojo-based eviction policy
> ----------------------------------------
>
>                 Key: JBCACHE-450
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-450
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> The eviction policy module has been refactored in 1.3. We will need to refactor the pojo-based evitction policy as well.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:06:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:06:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-750) PojoCache to deal
 with POJO without no-arg constructor
In-Reply-To: <3891836.1156726004669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31770532.1158462407583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-750?page=all ]

Ben Wang updated JBCACHE-750:
-----------------------------

    Fix Version/s: PojoCache 2.1.0
                       (was: PojoCache)

> PojoCache to deal with POJO without no-arg constructor
> ------------------------------------------------------
>
>                 Key: JBCACHE-750
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-750
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> This came up from a forum post that uses SynchronizedCollection. Here is the problem that Professor Chiba pointed out:
> ------
> Ben,
> SynchronizedRandomAccessList class has only the following constructors:
> static class SynchronizedRandomAccessList<E>
>          extends SynchronizedList<E>
>          implements RandomAccess {
>          SynchronizedRandomAccessList(List<E> list) {
>              super(list);
>          }
>          SynchronizedRandomAccessList(List<E> list, Object mutex) {
>              super(list, mutex);
>          }
>                 :
> }
> I can modify Javassist so that the above constructors (visible only within the pacakge) will be copied to the generated class.  But I am not sure that PojoCache can work with that generated class since it does not have a no-arg constructor.
> Chiba
> --------
> No easy solution to this problem now. Maybe use the exisiting serialization for once during replication?

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-157) Use privileged
 action in CacheInterceptor
Message-ID: <27732451.1158462528029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-157?page=all ]

Ben Wang updated JBCACHE-157:
-----------------------------

    Fix Version/s: 2.1.0
                       (was: 2.0.0)

This should be implemented along the overall context of JBoss Cache not just PojoCache.

> Use privileged action in CacheInterceptor
> -----------------------------------------
>
>                 Key: JBCACHE-157
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-157
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2.2
>         Environment: Standalone JDK 1.5 application with custom security policy
>            Reporter: twundke
>         Assigned To: Ben Wang
>             Fix For: 2.1.0
>
>         Attachments: CacheInterceptor.patch
>
>
> When using the AOP version of JBoss Cache in a security-managed environment, various classes require certain permissions (such as org.jboss.cache.aop.CachedType requiring java.lang.RuntimePermission "accessDeclaredMembers"). This also means that any class accessing a cached object must be granted these permissions.
> There are a number of problems with this. The first is that it breaks the transparency of using AOP-ed objects with the cache, as users of these objects must be granted additional permissions. The second problem is the nature of the permissions that must be granted. They are powerful permissions that allow runtime reflection, and in my particular case cannot be granted to the code using cached objects.
> The solution is to wrap the CacheInterceptor.invoke() method in a call to AccessController.doPrivileged() when a security manager is present. This allows the necessary permissions to be granted to the cache, without affecting the permissions of the calling code.
> The attached patch does just that. However, I don't know if this will have an effect on using the cache within a managed environment. I suspect not, but have no way of testing this.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-30) Multiple MBean
 Configuration Error
Message-ID: <4160664.1158462528183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-30?page=all ]

Ben Wang resolved JBCACHE-30.
-----------------------------

    Resolution: Out of Date

This will be out of date with our 2.0 release.

> Multiple MBean Configuration Error
> ----------------------------------
>
>                 Key: JBCACHE-30
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-30
>             Project: JBoss Cache
>          Issue Type: Bug
>    Affects Versions: 1.2
>            Reporter: SourceForge User
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> SourceForge Submitter: jiwils .
> Some if not all of the JBossCache configuration XML
> files contain the following commented MBean definition:
> <!--  Uncomment to get a graphical view of the
> TreeCache MBean above -->
>    <!--   <mbean code="org.jboss.cache.TreeCacheView"
> name="jboss.cache:service=TreeCacheView">-->
>    <!--     
> <depends>jboss.cache:service=TreeCache</depends>-->
>    <!--      <attribute
> name="CacheService">jboss.cache:service=TreeCache</attribute>-->
>    <!--   </mbean>-->	
> By uncommenting this MBean definition, I thought I
> would get a GUI with which I could inspect the cache,
> but instead I got a "multiple MBean" exception.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:10:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:10:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-589) PojoCache pojo
 level locking semantics
Message-ID: <26780947.1158462647407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-589?page=all ]

Ben Wang resolved JBCACHE-589.
------------------------------

    Resolution: Done

This is done via TxLockInterceptor.

> PojoCache pojo level locking semantics
> --------------------------------------
>
>                 Key: JBCACHE-589
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-589
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> When using pessimistic locking, we need to provide a pojo level locking semantics. Current one uses only node level and there is big problem when the node is not yet exist since we can't lock it that way. Idea maybe to provide an extra lock interceptor that tracks the pojo-level locking.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 02:22:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 02:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-695) PojoCache
 transaction context has limitation for in-memory rollbakck
In-Reply-To: <7160873.1152866171389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25504467.1158474167709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-695?page=all ]

Ben Wang updated JBCACHE-695:
-----------------------------

       Summary: PojoCache transaction context has limitation for in-memory rollbakck  (was: PojoCache transaction rollback has limitation under certain transaction context)
    Complexity: High

> PojoCache transaction context has limitation for in-memory rollbakck
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-695
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-695
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Currently PojoCache supports transaction rollback. For instance,
> cache.attach(id, pojo);
> is transactional even if there is no user transaction. However, with user transaction,
> tx.begin();
> cache.attach(id, pojo);
> pojo.setAge(20);
> tx.rollback();
> the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself:
> // Just make sure this one succeeds first.
> tx.begin();
> cache.attach(id, pojo);
> tx.commit();
> // All subsquent field update will be transactional then.
> tx.begin();
> pojo.setAge(20);
> tx.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

        


From jira-events at jboss.com  Sun Sep 17 02:22:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 02:22:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-695) PojoCache
 transaction context has limitation for in-memory rollbakck
In-Reply-To: <7160873.1152866171389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6215673.1158474168159.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-695?page=all ]

Ben Wang resolved JBCACHE-695.
------------------------------

    Resolution: Done

Has a InMemoryTxUndoTest to validate this. All in-memory state rollback should be handled properly as well.

> PojoCache transaction context has limitation for in-memory rollbakck
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-695
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-695
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Currently PojoCache supports transaction rollback. For instance,
> cache.attach(id, pojo);
> is transactional even if there is no user transaction. However, with user transaction,
> tx.begin();
> cache.attach(id, pojo);
> pojo.setAge(20);
> tx.rollback();
> the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself:
> // Just make sure this one succeeds first.
> tx.begin();
> cache.attach(id, pojo);
> tx.commit();
> // All subsquent field update will be transactional then.
> tx.begin();
> pojo.setAge(20);
> tx.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

        


From jira-events at jboss.com  Sun Sep 17 03:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-757) Problem updating
 cyclic reference
In-Reply-To: <30339271.1156937625656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22540775.1158476928808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-757?page=all ]

Ben Wang resolved JBCACHE-757.
------------------------------

    Resolution: Done

> Problem updating cyclic reference
> ---------------------------------
>
>                 Key: JBCACHE-757
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-757
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: J?rn Eyrich
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> import org.jboss.cache.aop.PojoCache;
> import org.jboss.cache.aop.annotation.PojoCacheable;
> @PojoCacheable
> public class Main {
> 	public Main reference;
> 	
> 	public static void main(String[] args) throws Exception {
> 	
> 		PojoCache cache = new PojoCache();
> 		cache.startService();
> 		
> 		Main main  = new Main();
> 		Main main2 = new Main();
> 		main.reference  = main2;
> 		main2.reference = main;
> 		
> 		cache.putObject("/main",main);
> 		main2.reference = main; // <--
> 		System.out.println("Done...");
> 	}
> }
> results in:
> Exception in thread "main" java.lang.RuntimeException: PojoCache.putObject(): fqn: /main/reference/reference
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478)
> 	at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:115)
> 	at org.jboss.aop.joinpoint.FieldWriteInvocation.invokeNext(FieldWriteInvocation.java:51)
> 	at Main.reference_w_$aop(Main.java)
> 	at Main.main(Main.java:21)
> Caused by: java.lang.IllegalStateException: AOPInstance.incrementRefCount(): source fqn: /main/reference/reference is already present.
> 	at org.jboss.cache.aop.AOPInstance.incrementRefCount(AOPInstance.java:92)
> 	at org.jboss.cache.aop.InternalDelegate.incrementRefCount(InternalDelegate.java:98)
> 	at org.jboss.cache.aop.ObjectGraphHandler.incrementRefCount(ObjectGraphHandler.java:212)
> 	at org.jboss.cache.aop.ObjectGraphHandler.setupRefCounting(ObjectGraphHandler.java:192)
> 	at org.jboss.cache.aop.ObjectGraphHandler.objectGraphPut(ObjectGraphHandler.java:88)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:201)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	... 4 more

-- 
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

       



From jira-events at jboss.com  Sun Sep 17 03:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-757) Problem updating
 cyclic reference
In-Reply-To: <30339271.1156937625656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4693780.1158476928480.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-757?page=comments#action_12343423 ] 
            
Ben Wang commented on JBCACHE-757:
----------------------------------

I have verified this in 2.0 release:

   public void testCircularReference8() throws Exception
   {
      log.info("testCircularReference8() ...");
      Link parent = new Link("parent");
      Link child = new Link("child");
      parent.setLink(child);
      child.setLink(parent);

      cache_.attach("parent", parent);
      parent.setLink(child); // again
      child.setLink(parent);
   }

and it works fine.

> Problem updating cyclic reference
> ---------------------------------
>
>                 Key: JBCACHE-757
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-757
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: J?rn Eyrich
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> import org.jboss.cache.aop.PojoCache;
> import org.jboss.cache.aop.annotation.PojoCacheable;
> @PojoCacheable
> public class Main {
> 	public Main reference;
> 	
> 	public static void main(String[] args) throws Exception {
> 	
> 		PojoCache cache = new PojoCache();
> 		cache.startService();
> 		
> 		Main main  = new Main();
> 		Main main2 = new Main();
> 		main.reference  = main2;
> 		main2.reference = main;
> 		
> 		cache.putObject("/main",main);
> 		main2.reference = main; // <--
> 		System.out.println("Done...");
> 	}
> }
> results in:
> Exception in thread "main" java.lang.RuntimeException: PojoCache.putObject(): fqn: /main/reference/reference
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478)
> 	at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:115)
> 	at org.jboss.aop.joinpoint.FieldWriteInvocation.invokeNext(FieldWriteInvocation.java:51)
> 	at Main.reference_w_$aop(Main.java)
> 	at Main.main(Main.java:21)
> Caused by: java.lang.IllegalStateException: AOPInstance.incrementRefCount(): source fqn: /main/reference/reference is already present.
> 	at org.jboss.cache.aop.AOPInstance.incrementRefCount(AOPInstance.java:92)
> 	at org.jboss.cache.aop.InternalDelegate.incrementRefCount(InternalDelegate.java:98)
> 	at org.jboss.cache.aop.ObjectGraphHandler.incrementRefCount(ObjectGraphHandler.java:212)
> 	at org.jboss.cache.aop.ObjectGraphHandler.setupRefCounting(ObjectGraphHandler.java:192)
> 	at org.jboss.cache.aop.ObjectGraphHandler.objectGraphPut(ObjectGraphHandler.java:88)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:201)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	... 4 more

-- 
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

       



From jira-events at jboss.com  Sun Sep 17 03:14:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-695) PojoCache
 transaction context has limitation for in-memory rollbakck
In-Reply-To: <7160873.1152866171389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28250366.1158477287538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-695?page=all ]

Ben Wang updated JBCACHE-695:
-----------------------------

    Priority: Critical  (was: Major)

> PojoCache transaction context has limitation for in-memory rollbakck
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-695
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-695
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Currently PojoCache supports transaction rollback. For instance,
> cache.attach(id, pojo);
> is transactional even if there is no user transaction. However, with user transaction,
> tx.begin();
> cache.attach(id, pojo);
> pojo.setAge(20);
> tx.rollback();
> the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself:
> // Just make sure this one succeeds first.
> tx.begin();
> cache.attach(id, pojo);
> tx.commit();
> // All subsquent field update will be transactional then.
> tx.begin();
> pojo.setAge(20);
> tx.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

        


From jira-events at jboss.com  Sun Sep 17 03:50:47 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sun, 17 Sep 2006 03:50:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-322) Provide 3 major
 default configurations (udp.xml, tcp.xml and tcp-nio.xml)
Message-ID: <7218240.1158479447973.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)
-------------------------------------------------------------------------

                 Key: JGRP-322
                 URL: http://jira.jboss.com/jira/browse/JGRP-322
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.2.9 SP4


Those configs should be the same in stacks.xml (for the Multiplexer) as well

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 03:58:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:58:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21258593.1158479928437.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Ben Wang resolved JBCACHE-765.
------------------------------

    Fix Version/s: 1.4.0.SP2
       Resolution: Done

Niztan, thanks!

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 1.4.0.SP2, 2.0.0
>
>         Attachments: CachedListAbstract.java, CachedListAbstract.java, CachedMapImpl.java, CachedMapImpl.java
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 04:06:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 04:06:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10933467.1158480408050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Ben Wang resolved JBCACHE-763.
------------------------------

    Resolution: Done

Fixed in 2.0. Test case is integrated into src-50/functional/o.j.c.pojo.rollback.MapTxUndoTest

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 04:30:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 04:30:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7258900.1158481847908.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Ben Wang resolved JBCACHE-760.
------------------------------

    Resolution: Done

1. Checked in both the test case and fix to 1.4.0SP2
2. Also fix it in 2.0. However, the notification event is different is 2.0 now.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 1.4.0.SP2, 2.0.0
>
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 05:25:39 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 05:25:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-771) PojoCache to have
 events reacting to transactional context
Message-ID: <5459146.1158485139891.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to have events reacting to transactional context
----------------------------------------------------------

                 Key: JBCACHE-771
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-771
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.1.0


Currently, the 2.0 POJO based events are not tx aware meaning they can't not react to tx rollback (and therefore not sending the events). If we want to acheieve the tx-based events, we will need to use event interceptor and react to before and afterCompletion, perhaps.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 05:29:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 05:29:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2619) Add a testcase to
 validate that a
 registering deployer can take priority over accepting deployments for which
 a deployer already exists
Message-ID: <2562581.1158485379955.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2619?page=all ]

Dimitris Andreadis updated JBAS-2619:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> Add a testcase to validate that a registering deployer can take priority over accepting deployments for which a deployer already exists
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2619
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Dimitris Andreadis
>
> EJB3Deployer needs to make sure it can process deployments *before* the 2.1 EJBDeployer.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:09:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:09:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3618) repository-zip target
 in
 build-release.xml doesn't consistently overwrite default config with all
In-Reply-To: <18718633.1157144863997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1764377.1158487778485.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3618?page=all ]

Dimitris Andreadis closed JBAS-3618.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

Added the overwrite=true flag

> repository-zip target in build-release.xml doesn't consistently overwrite default config with all
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3618
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3618
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Alex Pinkin
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
>    <target name="repository-zip"
>      description="Create a canonical binaries for the repository">
>      <mkdir dir="${version}/repository" />
>      <echo message="jboss.dist=${jboss.dist}" />
>      <!-- Create a unified server/lib directory -->
>      <copy todir="${jboss.dist}/server/lib">
>        <fileset dir="${jboss.dist}/server/minimal/lib" />
>        <fileset dir="${jboss.dist}/server/default/lib" />
>        <fileset dir="${jboss.dist}/server/all/lib" />
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.thirdparty}/quartz/lib" />
>      </copy>
>      <!-- Create a unified server/deploy directory -->
>      <copy todir="${jboss.dist}/server/deploy">
>        <fileset dir="${jboss.dist}/server/default/deploy" />
>        <fileset dir="${jboss.dist}/server/all/deploy">
>          <exclude name="jms/**" />
>        </fileset>
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.cvs.dir}/connector/output/lib">
>          <include name="quartz-ra.rar" />
>        </fileset>
>      </copy>
>      <copy todir="${jboss.dist}/server/deploy-ha">
>        <fileset dir="${jboss.dist}/server/all">
>          <include name="deploy/jms/**" />
>          <include name="deploy-hasingleton/**" />
>          <include name="farm/**" />
>        </fileset>
>      </copy>
> Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps.
> There is overwrite=true attribute which need to be added to force overwrites.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:19:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:19:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1714) -service.xml not
 deploying deploy/*.jar correctly
Message-ID: <12956311.1158488379438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1714?page=all ]

Dimitris Andreadis closed JBAS-1714.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Won't Fix

the classpath element is rarely used.

> -service.xml not deploying deploy/*.jar correctly
> -------------------------------------------------
>
>                 Key: JBAS-1714
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1714
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>            Reporter: SourceForge User
>
> SourceForge Submitter: ioparra .
> Refer to my previous postings in the forums:
> http://www.jboss.org/thread.jsp?
> forum=63&thread=36306
> The SAR Deployer is locking down jars in the deploy 
> directory instead of deploying those jars correctly.  This 
> event occurs when you have a "classpath" entry in your 
> mbean.  If that classpath has a codebase="."(ie, its 
> codebase is the deploy directory), this SAR Deployer 
> adds this jar to UCL repository.  
> Issues:
> 1)the url for this jar points to the deploy directory(not a 
> temp directory)
>     a. when the service is run, this jar is no longer 
> deleteable(on windows, dunno about unix).
> 2)The DirectoryScanner picks up this jar while scan.  
> The scanner copies/deploys the jar from the tmp 
> directory, leading to a new/managed UCL.  The 
> UCLRepository doesn't know its a duplicate becuase it 
> compares the URLs(one url is from deploy, the other 
> from tmp).
> Possible work-around/solution:
> The SAR deployer already does a check if the 
> classpath="."(ie, the deploy directory).  If true, call 
> mainDeployer.deploy(url) and don't call addURL.  I 
> don't know the full implications of making this change.  
> If I have time, I'll try it out and post a patch.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:23:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:23:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-293) dynamic-ql sort order
	problem
Message-ID: <16299038.1158488618097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-293?page=all ]

Dimitris Andreadis updated JBAS-293:
------------------------------------

      Component/s: CMP service
                       (was: EJB2)
    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> dynamic-ql sort order problem
> -----------------------------
>
>                 Key: JBAS-293
>                 URL: http://jira.jboss.com/jira/browse/JBAS-293
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>            Reporter: SourceForge User
>
> SourceForge Submitter: s2jcpete .
> Conectiva 8.0 
> JBoss-3.0.4 
> j2sdk-1.4.0_02 
>  
> When executing a dynamic-ql query in my CMP2.0 bean 
> everything gets returned correctly, but there is an issue with 
> the sorting.  It will not return the data properly sorted no 
> matter what field I ask to sort, or the ASC/DESC.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:25:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:25:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1535) PK Constraint name
 for Datbase Derby to long
Message-ID: <20712369.1158488739000.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1535?page=all ]

Dimitris Andreadis updated JBAS-1535:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> PK Constraint name for Datbase Derby to long
> --------------------------------------------
>
>                 Key: JBAS-1535
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1535
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.1 Final
>         Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded
>            Reporter: Ingo Bruell
>             Fix For: JBossAS-4.0.6.CR1
>
>
> In creating time of tables it could happen that a generated name for a pk constraint exceeds the limit of 18 characters.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:27:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1536) Wrong SQL Type for
 Boolean Mapping for Derby Database
Message-ID: <24271762.1158488863133.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1536?page=all ]

Dimitris Andreadis updated JBAS-1536:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Wrong SQL Type for Boolean Mapping for Derby Database
> -----------------------------------------------------
>
>                 Key: JBAS-1536
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1536
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.1 Final
>         Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded
>            Reporter: Ingo Bruell
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The SQL datatype 'BOOLEAN' is not a valid datatype for the derby database.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:29:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:29:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2193) abstract schema name
 with word limit in name
Message-ID: <29304285.1158488978694.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ]

Dimitris Andreadis updated JBAS-2193:
-------------------------------------

    Component/s:     (was: EJB2)
       Assignee: Alexey Loubyansky
       Priority: Minor  (was: Major)

> abstract schema name with word limit in name
> --------------------------------------------
>
>                 Key: JBAS-2193
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2193
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions:  JBossAS-4.0.3RC1
>         Environment: OS: Windows XP and FreeBsd
> Database: PostgreSQL 7.4
>            Reporter: Yura Kravchuk
>         Assigned To: Alexey Loubyansky
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly.
> Herewith exception:
> 17:02:28,671 INFO  [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ
> ory; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.
> Was expecting:
>     "FROM" ...
>     ; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:31:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:31:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3596) JNDI static cache
In-Reply-To: <3008714.1157125304199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6820712.1158489098486.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3596?page=all ]

Dimitris Andreadis updated JBAS-3596:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

If you want to investigate this for the next release, otherwise, close it.

> JNDI static cache
> -----------------
>
>                 Key: JBAS-3596
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3596
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>             Fix For: JBossAS-5.0.0.CR1, JBossAS-4.0.6.CR1
>
>
> Having a JNDI caching would improove performance on applications where JNDI is over used.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 09:12:47 2006
From: jira-events at jboss.com (Jason Lenhart (JIRA))
Date: Sun, 17 Sep 2006 09:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31150283.1158498767507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Jason Lenhart closed JBESB-128.
-------------------------------

    Resolution: Done

I looked through the current docs and it appears to been taken out.

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 09:14:47 2006
From: jira-events at jboss.com (Jason Lenhart (JIRA))
Date: Sun, 17 Sep 2006 09:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-129) Wrong jar referred to
 in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16229392.1158498887468.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Jason Lenhart closed JBESB-129.
-------------------------------

    Resolution: Done

Per Mark's comment, I added the following to the docs:

"We have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes."

We should probably just say that we have provided a driver - as the name on this will inevitably change.


> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 10:02:47 2006
From: jira-events at jboss.com (Mohit Keswani (JIRA))
Date: Sun, 17 Sep 2006 10:02:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-68) Tidy-up JDBC classes
Message-ID: <22834488.1158501767849.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mohit Keswani closed JBESB-68.
------------------------------

    Fix Version/s: 4.0 Beta 1
                       (was: 4.0)
       Resolution: Done

Modified all helpers/persist classes to throw SQLException
Modified method names to make them complete and logical.

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 13:44:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sun, 17 Sep 2006 13:44:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-354) Better support for
 JSF-style managed properties
In-Reply-To: <28874974.1158345394933.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13368840.1158515087461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-354?page=all ]

Gavin King closed JBSEAM-354.
-----------------------------

    Resolution: Rejected

Negative, this is already available with @RequestParameter, which is the only time it is useful (and is exactly the example you use). You will never need it any other time you use @In.

> Better support for JSF-style managed properties
> -----------------------------------------------
>
>                 Key: JBSEAM-354
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-354
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 1.0.1
>            Reporter: Adam Brod
>            Priority: Minor
>
> The @In annotation should support the same syntax as JSF managed properties.  That means that If I have this annotation in my Bean:
> @In("#{param.fileId}")
> Long fileId
> Seam should automatically inject that property performing the correct JSF conversion.  In Shale I can do that with the @Value or @Property annotation.  It is very confusing that I need a specialized annotation that doesn't support the EL just for request parameters when JSF doesn't make that distinction.
> I believe this could be implemented with a few small changes to Component.  Inside Component.getInstanceToInject(...), the logic which first checks to see if the name is an EL (line 1358 in Seam 1.0.1) could also check to see if the expression begins with "#{param.", if so, then it can call to Component.convertRequestParameter(...) to convert the type.
> This is a small change to Component, but it makes the overall Seam API more consistent.  It allows me to use the EL anywhere I want.  I don't have to worry about using @In or @RequestParameter, I just use the EL.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 14:16:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 17 Sep 2006 14:16:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3662) Add TCP_NIO tests to
 tests-clustering-all-stacks
Message-ID: <1585833.1158517007452.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add TCP_NIO tests to tests-clustering-all-stacks
------------------------------------------------

                 Key: JBAS-3662
                 URL: http://jira.jboss.com/jira/browse/JBAS-3662
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering, Test Suite
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


The mulitiplexer-stacks.xml file will have UDP, TCP and TCP_NIO configs.  Testsuite should excercise all 3, not just UDP and TCP.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 14:36:47 2006
From: jira-events at jboss.com (Alex Burgel (JIRA))
Date: Sun, 17 Sep 2006 14:36:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-751) unnecessary warning
 on valid process definition
Message-ID: <8319176.1158518207502.JavaMail.jira@cloud.prod.atl2.jboss.com>

unnecessary warning on valid process definition
-----------------------------------------------

                 Key: JBPM-751
                 URL: http://jira.jboss.com/jira/browse/JBPM-751
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Alex Burgel
         Assigned To: Tom Baeyens
            Priority: Trivial


i get this warning:

process xml warning: warning: no swimlane or assignment specified for task '<task xmlns="urn:jbpm.org:jpdl-3.1" name="schedule" blocking="false" signalling="true" priority="normal"/>'

it seems a bit odd to generate a warning on a valid process definition.

i think it should either be illegal to have a task without an assignment or swimlane, or there shouldn't be any warning at all (maybe lower the logging level to INFO).

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 14:50:47 2006
From: jira-events at jboss.com (Alex Burgel (JIRA))
Date: Sun, 17 Sep 2006 14:50:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-752) hibernate warnings in
 update HQL statements
Message-ID: <7268249.1158519047540.JavaMail.jira@cloud.prod.atl2.jboss.com>

hibernate warnings in update HQL statements
-------------------------------------------

                 Key: JBPM-752
                 URL: http://jira.jboss.com/jira/browse/JBPM-752
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Alex Burgel
         Assigned To: Tom Baeyens
            Priority: Trivial


i'm seeing a bunch of hibernate warnings in jbpm 3.1.2, with hibernate 3.1.3:

FromElementType - Using non-qualified column reference [id -> ([ID_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [processInstance -> ([PROCESSINSTANCE_])]

they are caused by update HQL statements in org.jbpm.db.hibernate.queries.hbm.xml. i think for update statements you have to be explicit about column references. you have to specify the table name or alias for each column, otherwise you'll get these warnings.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 15:24:47 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sun, 17 Sep 2006 15:24:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-498) Optimised HashMap
 implementations
Message-ID: <15791394.1158521087854.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimised HashMap implementations
---------------------------------

                 Key: JBRULES-498
                 URL: http://jira.jboss.com/jira/browse/JBRULES-498
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1


Create a HashMap implementation that is optimised for holding ReteTuples  and also for indexing FactHandles by field index  and value,

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 15:40:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 17 Sep 2006 15:40:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-772) State transfer not
 handled properly in case of reconnect
Message-ID: <1346641.1158522047451.JavaMail.jira@cloud.prod.atl2.jboss.com>

State transfer not handled properly in case of reconnect
--------------------------------------------------------

                 Key: JBCACHE-772
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-772
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 1.4.0.SP1, 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.2.4SP2, 1.2.4SP1, 1.2.4
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
             Fix For: 2.1.0


In createService(), TreeCache set Channel.AUTO_GET_STATE to true.  This should only be done if the cache is configured to do an initial state transfer.

That's easy to fix.  What's harder to fix is what to do when region-based marshalling is in effect. Probably, something like the following:

1) In viewAccepted, monitor for the case where a view is issue that doesn't include the current node.  Set a flag and ??? (throw exceptions when attempts are made to use the cache???)
2) When another view is accepted that once again includes the current node, iterate through the various marshalling regions, inactivating and then reactivating them (reactivation will cause a partial state transfer).

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 17:52:48 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 17:52:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-99) Renderer/Portal
 support for the mbean management views
Message-ID: <9764091.1158529968073.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-99?page=all ]

Julien Viet resolved JBPORTAL-99.
---------------------------------

    Resolution: Rejected

> Renderer/Portal support for the mbean management views
> ------------------------------------------------------
>
>                 Key: JBPORTAL-99
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-99
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Alpha
>            Reporter: Scott M Stark
>
> How can the existing jmx-console be updated to allow the non-trivial attribute and operation types to have meaningful html views? See the JBAS-52 linked case for the immeadiate usecase of a HtmlEditor.toHtml() type of functionality I'm looking for.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:08:50 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:08:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPTL-14) Add new parsers
Message-ID: <4363853.1158530930050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-14?page=all ]

Julien Viet resolved JBPTL-14.
------------------------------

    Resolution: Rejected

> Add new parsers
> ---------------
>
>                 Key: JBPTL-14
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-14
>             Project: JBoss Portal
>          Issue Type: Sub-task
>            Reporter: Julien Viet
>            Priority: Optional
>
> Add new parsers to the stack like full HTML or wiki

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:14:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-240) make header data
 available to jsp includes
Message-ID: <14420650.1158531287270.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-240?page=all ]

Julien Viet resolved JBPORTAL-240.
----------------------------------

    Fix Version/s: 2.4.1 Final
                   2.6.Alpha1
       Resolution: Duplicate Issue

> make header data available to jsp includes
> ------------------------------------------
>
>                 Key: JBPORTAL-240
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-240
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Beta 1
>            Reporter: joe hobson
>            Priority: Minor
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>
> The user-agent property is not currently being passed to the jsp that is included with the portlet's render response. According to the Building Portals with the Java Portlet API book, the request.getHeader() function should return the header from properties on the portlet request. I don't know enough about the JSR-168 spec to know whether this is a feature request or a bug. In JBP request.getHeader("user-agent") from an included jsp returns "null". Not sure about the other header info.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:18:48 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:18:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26073281.1158531528553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Julien Viet reassigned JBPORTAL-998:
------------------------------------

    Assignee: Thomas Heute

Thomas, either apply it, or resolve it, thanks.


> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:18:48 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:18:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25520430.1158531528795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Julien Viet updated JBPORTAL-998:
---------------------------------

    Affects Version/s: 2.2.1 Final
                           (was: 2.4 Final)

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:20:46 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:20:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPTL-55) Create a little
	parser for emails
Message-ID: <16630998.1158531646637.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-55?page=all ]

Julien Viet resolved JBPTL-55.
------------------------------

    Resolution: Out of Date

> Create a little parser for emails
> ---------------------------------
>
>                 Key: JBPTL-55
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-55
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Heute
>            Priority: Minor
>
> Would be nice to have a little parser for things like sending an email.
> A simple text file like:
> Hello {givenName} {familyName},
> This is your password as you requested:
> Passord: {password}
> --
> Thanks,
> The team
> That would be easily customizable and it would have to be i18nized (different text files for different countries).
> MessageFormat could simply be the way to go.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:20:46 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:20:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5303775.1158531646771.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=all ]

Julien Viet updated JBPORTAL-1034:
----------------------------------

    Fix Version/s: 2.6.Alpha1

You forgot to fill in the "fix version", field, please do it next time.

> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 1 week, 2 hours
>
> - define architecture, goals and roadmap for portal - ldap integration
> - prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:22:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-680) JBoss Portal
 does not pass
 through request attributes to the underlying delegate HttpServletRequest
 anymore. This creates a problem with applications created with JSF
 (myfaces) as these applications use request attributes to write headers
Message-ID: <25640827.1158531767088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-680?page=all ]

Julien Viet resolved JBPORTAL-680.
----------------------------------

    Resolution: Out of Date

> JBoss Portal does not pass through request attributes to the underlying delegate HttpServletRequest anymore. This creates a problem with applications created with JSF (myfaces) as these applications use request attributes to write headers
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-680
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-680
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.0.2 Final
>         Environment: ALL
>            Reporter: Swarn Dhaliwal
>            Priority: Critical
>
> PortalRequestImpl class does not pass through the request attributes to underlying HttpServletJRequest anymore. This creates a problem with some components written in Myfaces as these components use
> request attributes to emit headers to the enclosing document.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:22:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-305) How to define
 and extract user defined attributes in Jboss Portal/ portlet
Message-ID: <30198912.1158531767304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-305?page=all ]

Julien Viet resolved JBPORTAL-305.
----------------------------------

    Resolution: Rejected

JIRA is not a place to ask questions.

> How to define and extract user defined attributes in Jboss Portal/ portlet
> --------------------------------------------------------------------------
>
>                 Key: JBPORTAL-305
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-305
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>         Environment: Jboss portal 2.0
>            Reporter: David Huynh
>
> I have a few jsr 168 standard attributes defined in my porltet.xml; however, it  doesn't  show up when i try to  print out the user profile map even i have logged in. I  edit user profile and adde some values for some attributes and it start showing up but not first and last names, why?  Also, if  i want to define some attributes where i'm going to put them and how i extract them?  Thanks

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:22:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-482) Secure context
 path for
 servlets using a servlet in the portal that proxies the request and
 dispatch it to the target context using the security provided by the portal
 war file
Message-ID: <20126804.1158531767430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-482?page=all ]

Julien Viet resolved JBPORTAL-482.
----------------------------------

    Resolution: Rejected

Portlet 2.0 resource serving will provide that.

> Secure context path for servlets using a servlet in the portal that proxies the request and dispatch it to the target context using the security provided by the portal war file
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-482
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-482
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> This should provide more security for AJAX framework as the user identity should be propagated

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 23:22:47 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Sun, 17 Sep 2006 23:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20444213.1158549767549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Prabhat Jha resolved JBAS-3650.
-------------------------------

    Assignee: JBN Patch Team  (was: Prabhat Jha)

It did not cause any regression. Here is the md5sum:

e1d378f52c7e7e1caf38ea88ff117406  jbosssx.jar


> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: JBN Patch Team
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3662) Add TCP_NIO tests to
 tests-clustering-all-stacks
In-Reply-To: <1585833.1158517007452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2052018.1158552767300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3662?page=all ]

Brian Stansberry closed JBAS-3662.
----------------------------------

    Resolution: Done

> Add TCP_NIO tests to tests-clustering-all-stacks
> ------------------------------------------------
>
>                 Key: JBAS-3662
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3662
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The mulitiplexer-stacks.xml file will have UDP, TCP and TCP_NIO configs.  Testsuite should excercise all 3, not just UDP and TCP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3592) Add system property
 jgroups.mcast.ip_ttl
In-Reply-To: <13362282.1157048839355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20326210.1158552767411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3592?page=all ]

Brian Stansberry closed JBAS-3592.
----------------------------------

    Resolution: Done

> Add system property jgroups.mcast.ip_ttl
> ----------------------------------------
>
>                 Key: JBAS-3592
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3592
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> Add a system property to all JGroups multicast configs in the AS to control ip_ttl.  Update testsuite build.xml to set this to 1 so running the testsuite doesn't send traffic off the box.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3587) Add a system property
 to configure TCPPING.initial_hosts
In-Reply-To: <19247726.1156955263825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7604735.1158552767536.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3587?page=all ]

Brian Stansberry closed JBAS-3587.
----------------------------------

    Resolution: Done

> Add a system property to configure TCPPING.initial_hosts
> --------------------------------------------------------
>
>                 Key: JBAS-3587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:
> <TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...
> For now I'm going to go with just a system property.  If people want a startup switch they can request it.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3507) Add ability to toggle
 the MultiplexerStack between UDP- and TCP-based versions
In-Reply-To: <23746160.1155248952635.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33070177.1158552767668.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3507?page=all ]

Brian Stansberry closed JBAS-3507.
----------------------------------

    Resolution: Done

> Add ability to toggle the MultiplexerStack between UDP- and TCP-based versions
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-3507
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3507
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Need Branch_4_0-style "tests-clustering-all-stacks" tests, but simpler to implement due to ability to change the MultiplexerStack attribute.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:24:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:24:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-676) PojoCache map
 implementation needs to handle the case where key is PojoCacheable
Message-ID: <354515.1158553488593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-676?page=all ]

Ben Wang updated JBCACHE-676:
-----------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.)]

> PojoCache map implementation needs to handle the case where key is PojoCacheable
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-676
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-676
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> This is illustrated in org.jboss.cache.pojo.RecrusiveRefTest where we have map.put(valueId, valueObject) where both are PojoCacheable and valueId also embeded in valueObject. Therefore, if we treat valueId just as a Serializable, replication will cause the object reference split in valueObject (becuase in valueObject, valueId is treated by PojoCache).

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:24:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:24:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-676) PojoCache map
 implementation needs to handle the case where key is PojoCacheable
Message-ID: <28411056.1158553488780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-676?page=all ]

Ben Wang resolved JBCACHE-676.
------------------------------

    Resolution: Done

The test passes now in 2.0. Still need documentation of the effect of Id is Serializable only though.

> PojoCache map implementation needs to handle the case where key is PojoCacheable
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-676
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-676
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> This is illustrated in org.jboss.cache.pojo.RecrusiveRefTest where we have map.put(valueId, valueObject) where both are PojoCacheable and valueId also embeded in valueObject. Therefore, if we treat valueId just as a Serializable, replication will cause the object reference split in valueObject (becuase in valueObject, valueId is treated by PojoCache).

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:32:49 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-110) PojoCache
 overriding toString or hashCode can trigger stack overflow
Message-ID: <14875796.1158553969717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-110?page=all ]

Ben Wang updated JBCACHE-110:
-----------------------------

       Affects: [Documentation (Ref Guide, User Guide, etc.)]
    Complexity: High

> PojoCache overriding toString or hashCode can trigger stack overflow
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-110
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-110
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion.
> Kabir has done it in:
> org.jboss.aspects.dbc.DesignByContractAspect

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:34:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:34:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-110) PojoCache
 overriding toString or hashCode can trigger stack overflow
Message-ID: <12298833.1158554087900.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-110?page=comments#action_12343446 ] 
            
Ben Wang commented on JBCACHE-110:
----------------------------------

Currently, I have used an annotation @Reentrant and the following declaration in jboss-aop.xml:

   <!-- This bind the jointpoint to specific in-memory operations. Currently in PojoUtil. -->
   <bind pointcut="execution(*
      @org.jboss.cache.pojo.annotation.Reentrant->toString())">
      <interceptor-ref name="Reentrant"/>
   </bind>

   <!-- Interceptor to perform Pojo level rollback -->
   <interceptor name="Reentrant" class="org.jboss.cache.pojo.interceptors.MethodReentrancyStopperInterceptor"
                scope="PER_INSTANCE"/>

The annotation currently applies only to List, Set, and Map impl now.

> PojoCache overriding toString or hashCode can trigger stack overflow
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-110
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-110
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion.
> Kabir has done it in:
> org.jboss.aspects.dbc.DesignByContractAspect

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:34:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:34:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-110) PojoCache
 overriding toString or hashCode can trigger stack overflow
Message-ID: <13949858.1158554088020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-110?page=all ]

Ben Wang resolved JBCACHE-110.
------------------------------

    Resolution: Done

> PojoCache overriding toString or hashCode can trigger stack overflow
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-110
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-110
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion.
> Kabir has done it in:
> org.jboss.aspects.dbc.DesignByContractAspect

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:58:50 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:58:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <5083933.1158555530264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=all ]

Ben Wang updated JBCACHE-675:
-----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.)]
    Assignee: Ben Wang  (was: Scott Marlow)

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:00:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <6921269.1158555651524.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=comments#action_12343447 ] 
            
Ben Wang commented on JBCACHE-675:
----------------------------------

This test passes now in 2.0. Should also update the documentation.

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:00:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <3943952.1158555651635.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=all ]

Ben Wang resolved JBCACHE-675.
------------------------------

    Resolution: Done

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:00:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <11435950.1158555651770.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=comments#action_12343448 ] 
            
Ben Wang commented on JBCACHE-675:
----------------------------------

That is, in 2.0, we allow the Id key to be PojoCacheable as well as Serializable now.

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:02:50 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:02:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-732) PojoCache
 introduces @NonTransient annotation
In-Reply-To: <16046460.1155187212288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16252560.1158555770796.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-732?page=all ]

Ben Wang updated JBCACHE-732:
-----------------------------

    Fix Version/s: PojoCache 2.1.0
                       (was: 2.0.0)

> PojoCache introduces @NonTransient annotation
> ---------------------------------------------
>
>                 Key: JBCACHE-732
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-732
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>
> We need to introduce a @NonTransient annotation to override the transient modifier.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:04:50 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:04:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-163) Consolidate jboss
 related libraries
Message-ID: <22113600.1158555890985.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]

Ben Wang updated JBCACHE-163:
-----------------------------

    Assignee: Manik Surtani  (was: Ben Wang)

Manik, I am assigning this to you now since you have been doing it already.

> Consolidate jboss related libraries
> -----------------------------------
>
>                 Key: JBCACHE-163
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-163
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Currently the jboss dependent packaging in JBossCache is a bit scattered. We use the packaging from jboss-head but they are different the packaing, say, jboss-4.0. 
> For example, jboss head recently split jboss-j2ee.jar into jboss-j2ee and jboss-j2se.jar of which has no interests to us at all.
> Nonetheless, our dependency on jboss is very minimal now. So maybe we should think of consolidating all the jboss packaging into a single one? In theory, we should use the jboss packages from full release, like AS4.0.2.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:06:53 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:06:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-773) PojoCache to
 create an example for load-time option
Message-ID: <14816446.1158556013788.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to create an example for load-time option
---------------------------------------------------

                 Key: JBCACHE-773
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-773
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: 2.0.0


As titled.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:14:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 02:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-774) PojoCache to use a
 RPC layer to transmit POJO events
Message-ID: <22632405.1158560091387.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to use a RPC layer to transmit POJO events
----------------------------------------------------

                 Key: JBCACHE-774
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-774
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Critical
             Fix For: PojoCache 2.1.0


Currently, the POJO events does not propagate to other nodes since there is no way to do that. We will need some specific RPC mechanism to that such that we can broadcast POJO attach, detach, and modification events. This will also help to remove the POJO cache interceptor on the remote node as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:44:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 02:44:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1043) introduce
 UserProfile and user metadata (storage mechanism agnostic)
Message-ID: <21948155.1158561890633.JavaMail.jira@cloud.prod.atl2.jboss.com>

introduce UserProfile and user metadata (storage mechanism agnostic)
--------------------------------------------------------------------

                 Key: JBPORTAL-1043
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1043
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- Each user entry (ldap or database table) can bring different set of user personal information. This makes the user profile
- In portal we have property names like: user.name, user.surname, user.email, user.phone and etc.
- Each UserModule implementation provide a mapping of properties to coresponding values in underlaying database or directory  
 (table columns or ldat entry attributes for eg.)
- Profile informations are accessed using API like:  
  user.getMetaData().getProfileMetaData().getProperty(User.NAME_PROPERTY);
  .getAllProperties().iterator()
- Currently this is handled by PropertyMap - keept as separate table in DB

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:48:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 02:48:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1044) test cases
 against LDAP implementation of identity modules
Message-ID: <32353706.1158562130447.JavaMail.jira@cloud.prod.atl2.jboss.com>

test cases against LDAP implementation of identity modules
----------------------------------------------------------

                 Key: JBPORTAL-1044
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1044
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- Testing in identity module should be implemented to perform implementation agnostic tests on different implementations of UserModule and RoleModule
- UserTestCase -> DBUserTestCase
- Introduce LDAPUserTestCase
- both reuse UserTest code so we can perform same tests on different implementations

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:54:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 02:54:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
Message-ID: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>

port OpenDS integration from JBoss AS testsuite to portal testsuite
-------------------------------------------------------------------

                 Key: JBPORTAL-1045
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Test
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 03:22:55 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Mon, 18 Sep 2006 03:22:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3663) JBoss Application
 Server Start Error
Message-ID: <21860359.1158564175530.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Application Server Start Error
------------------------------------

                 Key: JBAS-3663
                 URL: http://jira.jboss.com/jira/browse/JBAS-3663
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.1 SP1
         Environment: Windows 2000 Professional
            Reporter: madan srinivas
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.1 SP1


C:\jboss-4.0.1sp1\bin>run
===============================================================================
.
  JBoss Bootstrap Environment
.
  JBOSS_HOME: C:\jboss-4.0.1sp1\bin\\..
.
  JAVA: C:\Program Files\Java\jdk1.5.0_06\bin\java
.
  JAVA_OPTS:  -Dprogram.name=run.bat -Xms128m -Xmx512m
.
  CLASSPATH: C:\Program Files\Java\jdk1.5.0_06\lib\tools.jar;C:\jboss-4.0.1sp1\b
in\\run.jar
.
===============================================================================
.
10:04:24,284 INFO  [Server] Starting JBoss (MX MicroKernel)...
10:04:24,284 INFO  [Server] Release ID: JBoss [Zion] 4.0.1sp1 (build: CVSTag=JBo
ss_4_0_1_SP1 date=200502160314)
10:04:24,284 INFO  [Server] Home Dir: C:\jboss-4.0.1sp1
10:04:24,284 INFO  [Server] Home URL: file:/C:/jboss-4.0.1sp1/
10:04:24,284 INFO  [Server] Library URL: file:/C:/jboss-4.0.1sp1/lib/
10:04:24,284 INFO  [Server] Patch URL: null
10:04:24,284 INFO  [Server] Server Name: default
10:04:24,284 INFO  [Server] Server Home Dir: C:\jboss-4.0.1sp1\server\default
10:04:24,284 INFO  [Server] Server Home URL: file:/C:/jboss-4.0.1sp1/server/defa
ult/
10:04:24,284 INFO  [Server] Server Data Dir: C:\jboss-4.0.1sp1\server\default\da
ta
10:04:24,284 INFO  [Server] Server Temp Dir: C:\jboss-4.0.1sp1\server\default\tm
p
10:04:24,284 INFO  [Server] Server Config URL: file:/C:/jboss-4.0.1sp1/server/de
fault/conf/
10:04:24,284 INFO  [Server] Server Library URL: file:/C:/jboss-4.0.1sp1/server/d
efault/lib/
10:04:24,284 INFO  [Server] Root Deployment Filename: jboss-service.xml
10:04:24,299 INFO  [Server] Starting General Purpose Architecture (GPA)...
10:04:24,596 INFO  [ServerInfo] Java version: 1.5.0_06,Sun Microsystems Inc.
10:04:24,596 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_06-b05
,Sun Microsystems Inc.
10:04:24,596 INFO  [ServerInfo] OS-System: Windows 2000 5.0,x86
10:04:24,909 INFO  [Server] Core system initialized
10:04:26,831 ERROR [MainDeployer] could not create deployment: file:/C:/jboss-4.
0.1sp1/server/default/conf/jboss-service.xml
org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
.UndeclaredThrowableException)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:143)
        at org.jboss.system.ServiceController.install(ServiceController.java:200
)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy4.install(Unknown Source)
        at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:122)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:131)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
        at org.jboss.Main.boot(Main.java:162)
        at org.jboss.Main$1.run(Main.java:423)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.UndeclaredThrowableException
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
tor.java:153)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:118)
        ... 36 more
Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
ld/putstatic
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
        at java.lang.Class.getConstructor0(Class.java:2640)
        at java.lang.Class.getConstructor(Class.java:1629)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
1211)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
269)
        at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
327)
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
        ... 38 more
Failed to boot JBoss:
org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
.UndeclaredThrowableException)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:143)
        at org.jboss.system.ServiceController.install(ServiceController.java:200
)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy4.install(Unknown Source)
        at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:122)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:131)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
        at org.jboss.Main.boot(Main.java:162)
        at org.jboss.Main$1.run(Main.java:423)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.UndeclaredThrowableException
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
tor.java:153)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:118)
        ... 36 more
Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
ld/putstatic
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
        at java.lang.Class.getConstructor0(Class.java:2640)
        at java.lang.Class.getConstructor(Class.java:1629)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
1211)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
269)
        at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
327)
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
        ... 38 more
10:04:26,877 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages
Shutting down
10:04:26,877 INFO  [Server] Shutdown complete
Shutdown complete
Halting VM
Press any key to continue . . .

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:18:52 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 04:18:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3663) JBoss Application
 Server Start Error
In-Reply-To: <21860359.1158564175530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8380437.1158567532088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3663?page=all ]

Dimitris Andreadis closed JBAS-3663.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.1 SP1)
       Resolution: Rejected

Something's wrong with your distribution, so validate the md5 signature of your .zip file.

> JBoss Application Server Start Error
> ------------------------------------
>
>                 Key: JBAS-3663
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3663
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.1 SP1
>         Environment: Windows 2000 Professional
>            Reporter: madan srinivas
>         Assigned To: Dimitris Andreadis
>
> C:\jboss-4.0.1sp1\bin>run
> ===============================================================================
> .
>   JBoss Bootstrap Environment
> .
>   JBOSS_HOME: C:\jboss-4.0.1sp1\bin\\..
> .
>   JAVA: C:\Program Files\Java\jdk1.5.0_06\bin\java
> .
>   JAVA_OPTS:  -Dprogram.name=run.bat -Xms128m -Xmx512m
> .
>   CLASSPATH: C:\Program Files\Java\jdk1.5.0_06\lib\tools.jar;C:\jboss-4.0.1sp1\b
> in\\run.jar
> .
> ===============================================================================
> .
> 10:04:24,284 INFO  [Server] Starting JBoss (MX MicroKernel)...
> 10:04:24,284 INFO  [Server] Release ID: JBoss [Zion] 4.0.1sp1 (build: CVSTag=JBo
> ss_4_0_1_SP1 date=200502160314)
> 10:04:24,284 INFO  [Server] Home Dir: C:\jboss-4.0.1sp1
> 10:04:24,284 INFO  [Server] Home URL: file:/C:/jboss-4.0.1sp1/
> 10:04:24,284 INFO  [Server] Library URL: file:/C:/jboss-4.0.1sp1/lib/
> 10:04:24,284 INFO  [Server] Patch URL: null
> 10:04:24,284 INFO  [Server] Server Name: default
> 10:04:24,284 INFO  [Server] Server Home Dir: C:\jboss-4.0.1sp1\server\default
> 10:04:24,284 INFO  [Server] Server Home URL: file:/C:/jboss-4.0.1sp1/server/defa
> ult/
> 10:04:24,284 INFO  [Server] Server Data Dir: C:\jboss-4.0.1sp1\server\default\da
> ta
> 10:04:24,284 INFO  [Server] Server Temp Dir: C:\jboss-4.0.1sp1\server\default\tm
> p
> 10:04:24,284 INFO  [Server] Server Config URL: file:/C:/jboss-4.0.1sp1/server/de
> fault/conf/
> 10:04:24,284 INFO  [Server] Server Library URL: file:/C:/jboss-4.0.1sp1/server/d
> efault/lib/
> 10:04:24,284 INFO  [Server] Root Deployment Filename: jboss-service.xml
> 10:04:24,299 INFO  [Server] Starting General Purpose Architecture (GPA)...
> 10:04:24,596 INFO  [ServerInfo] Java version: 1.5.0_06,Sun Microsystems Inc.
> 10:04:24,596 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_06-b05
> ,Sun Microsystems Inc.
> 10:04:24,596 INFO  [ServerInfo] OS-System: Windows 2000 5.0,x86
> 10:04:24,909 INFO  [Server] Core system initialized
> 10:04:26,831 ERROR [MainDeployer] could not create deployment: file:/C:/jboss-4.
> 0.1sp1/server/default/conf/jboss-service.xml
> org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
> .UndeclaredThrowableException)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :143)
>         at org.jboss.system.ServiceController.install(ServiceController.java:200
> )
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy4.install(Unknown Source)
>         at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:122)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:131)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
>         at org.jboss.Main.boot(Main.java:162)
>         at org.jboss.Main$1.run(Main.java:423)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.reflect.UndeclaredThrowableException
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
>         at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
> tor.java:153)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :118)
>         ... 36 more
> Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
> ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
> ld/putstatic
>         at java.lang.Class.getDeclaredConstructors0(Native Method)
>         at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
>         at java.lang.Class.getConstructor0(Class.java:2640)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 1211)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 269)
>         at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
> 327)
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
>         ... 38 more
> Failed to boot JBoss:
> org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
> .UndeclaredThrowableException)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :143)
>         at org.jboss.system.ServiceController.install(ServiceController.java:200
> )
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy4.install(Unknown Source)
>         at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:122)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:131)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
>         at org.jboss.Main.boot(Main.java:162)
>         at org.jboss.Main$1.run(Main.java:423)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.reflect.UndeclaredThrowableException
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
>         at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
> tor.java:153)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :118)
>         ... 36 more
> Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
> ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
> ld/putstatic
>         at java.lang.Class.getDeclaredConstructors0(Native Method)
>         at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
>         at java.lang.Class.getConstructor0(Class.java:2640)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 1211)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 269)
>         at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
> 327)
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
>         ... 38 more
> 10:04:26,877 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages
> Shutting down
> 10:04:26,877 INFO  [Server] Shutdown complete
> Shutdown complete
> Halting VM
> Press any key to continue . . .

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:22:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:22:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1046) documentation
 for Ldap/Portal integration
Message-ID: <28666807.1158567770641.JavaMail.jira@cloud.prod.atl2.jboss.com>

documentation for Ldap/Portal integration
-----------------------------------------

                 Key: JBPORTAL-1046
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1046
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Create documentation of configuring Portal with LDAP. It needs to cover new implementation of identity modules in 2.6

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:32:52 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:32:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1047) Design ldap
 implementation for identity modules
Message-ID: <3389991.1158568372948.JavaMail.jira@cloud.prod.atl2.jboss.com>

Design ldap implementation for identity modules
-----------------------------------------------

                 Key: JBPORTAL-1047
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1047
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- Identity modules must handle both user/role retreival and creation 
- User and roles can be mapped in ldap directory tree in several different ways.
- There should be some flexible implementation desinged to handle different user/roles relations mapping strategies. (roles, group, both static and dynamic)
- This should also be opened for additional specific features for main LDAP implementations (RH, Sun, MSAD...)


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:34:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:34:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1048) Implementations
 of LDAP identity modules
Message-ID: <23673939.1158568490982.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implementations of LDAP identity modules
----------------------------------------

                 Key: JBPORTAL-1048
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1048
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Implementations of LDAP identity modules
like designed in: JBPORTAL-1047


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:36:51 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1049) LDAP integration
 in JBoss Portal
Message-ID: <11506068.1158568611696.JavaMail.jira@cloud.prod.atl2.jboss.com>

LDAP integration in JBoss Portal
--------------------------------

                 Key: JBPORTAL-1049
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1049
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Grouping task for all ldap issues in portal for 2.6

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:06:51 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Mon, 18 Sep 2006 05:06:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3664) Deploying EJB3.0
	entity bean
Message-ID: <4578824.1158570411764.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deploying EJB3.0 entity bean
----------------------------

                 Key: JBAS-3664
                 URL: http://jira.jboss.com/jira/browse/JBAS-3664
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.1 SP1
         Environment: Windows 2000 Professional
            Reporter: madan srinivas
         Assigned To: Dimitris Andreadis


Hi,
I am deploying EJB3.0 Entity bean on JBoss 4.0.1sp1.
I am having ejb-jar.xml and persistence.xml in my META-INF and 
Entity bean is not using any Remote Interface; as another Stateless SessionBean is instantiating the POJO Entitbean FileDetailsServiceBO and using EntityManager for persistence.

I get following error , Pls help.

14:29:31,163 WARN  [verifier] EJB spec violation:
Bean   : FileDetailsServiceBO
Section: 10.6.2
Warning: The entity bean's class must implement, directly or indirectly, the javax.ejb.EntityBean interface.

14:29:31,163 WARN  [verifier] EJB spec violation:
Bean   : FileDetailsServiceBO
Section: 10.6.2
Warning: The entity bean class must be defined as public and abstract.

14:29:31,163 WARN  [verifier] EJB spec violation:
Bean   : FileDetailsServiceBO
Section: 10.6.1
Warning: The Bean Provider must provide a remote interface and a remote home int
erface or a local interface and a local home interface for the bean.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:14:58 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 05:14:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3664) Deploying EJB3.0
	entity bean
In-Reply-To: <4578824.1158570411764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20026409.1158570898034.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3664?page=all ]

Dimitris Andreadis closed JBAS-3664.
------------------------------------

    Resolution: Rejected

Please use the forums to ask for help, JIRA is not the right place.

And use the installer of one of the latest jboss releases to get an ejb3 enabled configuration.

> Deploying EJB3.0 entity bean
> ----------------------------
>
>                 Key: JBAS-3664
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3664
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.1 SP1
>         Environment: Windows 2000 Professional
>            Reporter: madan srinivas
>         Assigned To: Dimitris Andreadis
>
> Hi,
> I am deploying EJB3.0 Entity bean on JBoss 4.0.1sp1.
> I am having ejb-jar.xml and persistence.xml in my META-INF and 
> Entity bean is not using any Remote Interface; as another Stateless SessionBean is instantiating the POJO Entitbean FileDetailsServiceBO and using EntityManager for persistence.
> I get following error , Pls help.
> 14:29:31,163 WARN  [verifier] EJB spec violation:
> Bean   : FileDetailsServiceBO
> Section: 10.6.2
> Warning: The entity bean's class must implement, directly or indirectly, the javax.ejb.EntityBean interface.
> 14:29:31,163 WARN  [verifier] EJB spec violation:
> Bean   : FileDetailsServiceBO
> Section: 10.6.2
> Warning: The entity bean class must be defined as public and abstract.
> 14:29:31,163 WARN  [verifier] EJB spec violation:
> Bean   : FileDetailsServiceBO
> Section: 10.6.1
> Warning: The Bean Provider must provide a remote interface and a remote home int
> erface or a local interface and a local home interface for the bean.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:16:59 2006
From: jira-events at jboss.com (Maurice Zeijen (JIRA))
Date: Mon, 18 Sep 2006 05:16:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10453667.1158571019100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=comments#action_12343455 ] 
            
Maurice Zeijen commented on JBSEAM-347:
---------------------------------------

I discoverd that this problem has to do with myFaces. If you make sure that myFaces doesn't get initialized (via web.xml or the .tld) then this exception doesn't happen.

> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:49:57 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Mon, 18 Sep 2006 05:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-148) Include
 Tomcat's
 SavedRequest object into the replication process in a Jboss-Tomcat
 clustered environment to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17498840.1158572997453.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=comments#action_12343457 ] 
            
Alberto Rodriguez commented on JBCLUSTER-148:
---------------------------------------------

An issue at tomcat's issue traker was opened, the discussion can be followed here: http://issues.apache.org/bugzilla/show_bug.cgi?id=40531

> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:52:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 05:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3346)
 org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase
 causes 1.5 BEA JVM to core dump
Message-ID: <27420000.1158573121064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3346?page=all ]

Dimitris Andreadis reassigned JBAS-3346:
----------------------------------------

    Assignee: Dimitris Andreadis

> org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase causes 1.5 BEA JVM to core dump
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3346
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: RHEL 4, x86_64 processor, BEA 1,5 JDK
>            Reporter: Len DiMaggio
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> With this JDK:
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> BEA JRockit(R) (build dra-45238-20050523-2021-linux-x86_64, R25.2.0-28)
> And this test from the JBoss 4.0.4/GA test suite (download from jboss.com) - the test causes a code dump when it executes line 62.
>      1	/*
>      2	* JBoss, Home of Professional Open Source
>      3	* Copyright 2005, JBoss Inc., and individual contributors as indicated
>      4	* by the @authors tag. See the copyright.txt in the distribution for a
>      5	* full listing of individual contributors.
>      6	*
>      7	* This is free software; you can redistribute it and/or modify it
>      8	* under the terms of the GNU Lesser General Public License as
>      9	* published by the Free Software Foundation; either version 2.1 of
>     10	* the License, or (at your option) any later version.
>     11	*
>     12	* This software is distributed in the hope that it will be useful,
>     13	* but WITHOUT ANY WARRANTY; without even the implied warranty of
>     14	* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>     15	* Lesser General Public License for more details.
>     16	*
>     17	* You should have received a copy of the GNU Lesser General Public
>     18	* License along with this software; if not, write to the Free
>     19	* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>     20	* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>     21	*/
>     22	package org.jboss.test.cmp2.batchcascadedelete.test;
>     23	
>     24	import org.jboss.test.JBossTestCase;
>     25	import org.jboss.test.cmp2.batchcascadedelete.ejb.Child;
>     26	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildHome;
>     27	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildUtil;
>     28	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildHome;
>     29	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildUtil;
>     30	import org.jboss.test.cmp2.batchcascadedelete.ejb.Parent;
>     31	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentHome;
>     32	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentUtil;
>     33	import junit.framework.Test;
>     34	
>     35	/**
>     36	 * @author <a href="mailto:alex at jboss.org">Alexey Loubyansky</a>
>     37	 * @version <tt>$Revision: 1.1.2.2 $</tt>
>     38	 */
>     39	public class BatchCascadeDeleteUnitTestCase
>     40	   extends JBossTestCase
>     41	{
>     42	   /**
>     43	    * Constructor for the JBossTestCase object
>     44	    *
>     45	    * @param name Test case name
>     46	    */
>     47	   public BatchCascadeDeleteUnitTestCase(String name)
>     48	   {
>     49	      super(name);
>     50	   }
>     51	
>     52	   public static Test suite() throws Exception
>     53	   {
>     54	      return JBossTestCase.getDeploySetup(BatchCascadeDeleteUnitTestCase.class, "cmp2-batchcascadedelete.jar");
>     55	   }
>     56	
>     57	   public void testCase4540() throws Exception
>     58	   {
>     59	      ParentHome parentHome = ParentUtil.getHome();
>     60	      Parent parent = parentHome.create("parent");
>     61	
>     62	      ChildHome childHome = ChildUtil.getHome();
>     63	      Child child = childHome.create( parent, "child");
>     64	
>     65	      GrandchildHome grandchildHome = GrandchildUtil.getHome();
>     66	
>     67	      // If you comment out the next line, then the call to child.remove() works fine.
>     68	      grandchildHome.create(child.getId(), "grandchild");
>     69	
>     70	      this is the test for non-null foreign key
>     71	      child.remove();
>     72	   }
>     73	}
> Here's the dump file:
> Linux x86_64-4as.lab.boston.redhat.com 2.6.9-39.ELsmp #1 SMP Thu Jun 1 18:01:55 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> ===== BEGIN DUMP =============================================================
> JRockit dump produced after 0 days, 00:29:38 on Wed Jun 21 13:56:36 2006
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Error Message: Illegal memory access. [54]
> Signal info  : si_signo=12, si_code=-6
> Version      : BEA JRockit(R) R25.2.0-28 dra-45238-20050523-2021-linux-x86_64
> GC           : System optimized over throughput (initial strategy singleparpar)
>              : GC strategy for GC 4 was genparpar
>              : GC strategy for GC 5 was singleparpar
>              : GC strategy for GC 6 was genparpar
>              : GC strategy for GC 7 was singleparpar
>              : GC strategy for GC 8 was genparpar
>              : mmHeap->data = 0x20000000, mmHeap->top = 0x28000000
>              : mmStartCompaction = 0x21800000, mmEndCompaction = 0x22000000
> CPU          : Intel Pentium 4 SSE SSE2 NetBurst EM64T
> Number CPUs  : 2
> Tot Phys Mem : 4120244224
> OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 4 Beta)
> Linux version 2.6.9-39.ELsmp (bhcompile at hs20-bc1-6.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Thu Jun 1 18:01:55 EDT 2006
> State        : JVM is running (Main thread has finished)
> Command Line : -Djrockit.launcher.type=jrockit.shipment -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/lib/endorsed org.jboss.Main -c all
> Environment  : JAVA_HOME=(null), java.home=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre, java.class.path=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar, java.library.path=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/../lib/amd64
> C Heap       : Good; no memory allocations have failed
> Registers (from context struct at 0x40e899f8/0x40e89a70):
> RAX = ffffffff00000010  RBX = 00000000f7bc5de8
> RCX = 00000000f7bc5df8  RDX = 00000000ffcb1bf3
> R8  = 000000000002feeb  R9  = 000000009090feeb
> R10 = 0000002a9b7aeed0  R11 = 0000002a9577893c
> R12 = 0000000040e89e58  R13 = 0000000000000001
> R14 = 0000000000000001  R15 = 0000002a9b7aed08
> RSI = 0000000020c8bb78  RDI = 00000000220b1108
> RSP = 0000000040e89eb0  RIP = 00000001009ccec8
> RBP = 00000000220b1108  RFL = 00000206
> CS = 0000 GS = 0000 FS = 0000
> Stack:
> 0000000040e89eb0: 0000000021ff0238 00000001009ccbb5 00000000220d6b28 0000000020c81130 0000000022078920 0000000021ff0238 
> 0000000040e89ee0: 0000000100000a22 0000000003c3d730 00000000220d6b40 0000000020c8bb48 0000000022078920 0000000021ff0238 
> 0000000040e89f10: 00000001009ca128 00000001009c9fdf 0000000022078920 0000000020c70cb0 00000000220b22a8 00000000220924a8 
> 0000000040e89f40: 0000000020c8bb48 0000000021ff0238 0000000022078920 0000000020c6ed78 00000001009c9c23 0000000020c6ee40 
> 0000000040e89f70: 0000000100000a45 000000000000001c 0000000021ff0238 0000000020c6ed78 0000000022078920 0000000021ff0238 
> 0000000040e89fa0: 00000001009c9b55 0000000020c137d8 00000001009c8e0f 0000000000000000 0000000022078920 0000000020b0b3b8 
> 0000000040e89fd0: 0000000021ff0238 0000000020c8b568 0000000000000000 0000000021ff0238 0000000020c137d8 0000000021ff0238 
> 0000000040e8a000: 0000000021ff0238 00000001009c8cb5 0000000020c0f3d8 00000001009c8bd4 0000000020c10a90 0000000003c064b0 
> 0000000040e8a030: 0000000021ff0238 0000000020c0f3d8 00000001009c8a8f 0000000003c057f0 0000000020a5ddb0 00000000220924a8 
> 0000000040e8a060: 00000001009c8296 0000000000000001 0000002a9b7aed08 000000010000090f 00000000005d7cd0 0000002a9b7aeed0 
> 0000000040e8a090: 00000000a6bf41f8 0000000020c0dca8 0000000021ff0238 0000000000000000 0000000020a5ddb0 0000000003bffb80 
> 0000000040e8a0c0: 0000000021ff0238 0000000000000000 0000000020a5ddb0 00000000220924a8 00000001009c7386 0000000020a5ddb0 
> 0000000040e8a0f0: 03c028209b7aed08 0000002a9b7aeed8 0000000020c0dca8 0000000000000000 00000000220924a8 0000000021ff0238 
> 0000000040e8a120: 0000000000000000 00000000220924a8 000000000000012c 0000002a9b7aeed0 0000000100000000 000000010002bdf0 
> 0000000040e8a150: 0000000020c08a38 0000000020a5ddb0 0000000100000a22 0000000003c00cf8 0000000000000001 00000000274b8c38 
> 0000000040e8a180: 0000000020c08a38 0000000021ff0238 00000001009c6da7 0000000100000a45 0000000020c0dca8 0000000021ff0238 
> 0000000040e8a1b0: 0000000000000000 0000000000000000 0000000021ff0238 00000001009c62a0 0000000021ff0238 0000000020c07368 
> 0000000040e8a1e0: 00000001009c612a 00000000005d7c90 0000000020c07368 0000000021ff0238 0000000021103b10 0000000000000000 
> 0000000040e8a210: 0000000021ff0238 0000000100000a45 000000000000001c 0000002a969f1010 0000000003bf6978 0000000020c05d48 
> 0000000040e8a240: 0000000021ff0238 00000001009c5b5f 0000000021ff0238 0000000000000000 0000000021ff4240 0000000020c05d48 
> 0000000040e8a270: 0000000021ff0238 0000000020b0b3b8 0000000021ff0238 00000001009c58b4 00000000210fb030 0000000040e8a3e0 
> 0000000040e8a2a0: 0000000020a5ddb0 00000001009c4f23 00000000269f9f90 0000000020b0b3b8 0000000021ff0238 0000000021033388 
> 0000000040e8a2d0: 0000010bf7bc5c80 00000000210fb030 0000002a00000001 0000000000000000 0000002a9b7aed08 0000002a956ad0b1 
> 0000000040e8a300: 000000000000029c 0000000002645f21 0000002a9b7aeec0 0000000040e8a598 0000000040e8a3e0 0000000040e8a560 
> 0000000040e8a330: 0000000100030068 0000000040e8a4f8 0000000040e8a3e0 00000001009c4b10 0000002a9b7aeb20 0000002a9b7aed08 
> 0000000040e8a360: 0000000000000001 0000000000000001 0000000040e8a3e0 0000002a9b7aed08 000000000064ca60 0000002a9560787a 
> 0000000040e8a390: 0000000000000002 0000002a956d3107 0000000103bb9370 000000000056aaa8 0000000040e8a500 0000002a9b7aee48 
> 0000000040e8a3c0: 0000002a9b7b3b00 0000002a956aca24 0000000003bb9370 0000000002643f80 0000002a9b7aee48 0000002a9b7aeec0 
> 0000000040e8a3f0: 0000000000000000 0000000100000000 0000000100000001 0000002a9b7aed28 0000000003bb9370 0000002a9b7aed08 
> 0000000040e8a420: 000000000056aaa8 0000000100000007 0000000200000001 0000000200000000 0000002a00000000 0000002a956c3228 
> 0000000040e8a450: 03bc261800000000 0000000002643f80 0000002a9b7aed08 0000002a9b7b3b00 0000002a9b7aee48 0000002a956c36f0 
> 0000000040e8a480: 0000000000000000 0000002a956c337c 0000002a956c36f0 0000000040e8a4f8 0000000040e8a500 0000000002643f80 
> 0000000040e8a4b0: 0000000000000001 0000002a9b7aee48 0000000000000000 0000002a9b7aed08 0000000002643f80 0000002a956c37c9 
> 0000000040e8a4e0: 011f3cc000000000 0000000040e8a4f8 000000010003af7a 0000002a9b7aeec8 0000000040e8a598 0000002a9b7aed08 
> 0000000040e8a510: 00000001001ecc8b 0000002a9b7aee58 0000002a9b7aeb20 0000000040e8a560 0000000000000001 0000000000000001 
> 0000000040e8a540: 0000002a9b7aed08 0000002a956cc14a 0000002a9b7aee48 000000010003c1e0 0000000000688b30 0000002a9b7aee48 
> 0000000040e8a570: 000000002192dec8 000000010003bfa7 0000000020b0b3b8 0000000021ff6d58 000000010003bea6 0000000021ff6be8 
> 0000000040e8a5a0: 0000000021ff6d58 0000000020b0b3b8 0000000021ff6be8 0000000100000001 0000000020b0b3b8 0000000020b0b3b8 
> 0000000040e8a5d0: 0000000021ff6be8 000000010005db3e 0000000021ff6be8 0000000021ff6d58 0000000020b0b3b8 0000000021ff6d98 
> 0000000040e8a600: 000000010003bd09 0000000021ff6be8 0000000021ff6be8 0000000021ff6be8 0000000020fa8d58 000000010003b2d5 
> 0000000040e8a630: 0000000021ff6be8 0000000020b0b3b8 0000000001939c68 0000000100003945 00000000200a1118 0000000025179958 
> 0000000040e8a660: 0000000000000001 000000000193de20 0000000021ff6c80 0000000020fa8d58 000000010023c5c8 0000000021ff6be8 
> 0000000040e8a690: 00000000ffffffff 0000000021ff6d10 0000000020ffd028 0000000021ff6c80 0000000020fa8d58 0000000020b0b3b8 
> Code:
> 00000001009ccdc8: 894890ff672533e8 c3d2f8252c8b48f3 0001025188b84803 ff6362c8e8000000 0e7ee82824748948 482824748b48ff67 
> 00000001009ccdf8: 00002a9b7ca2b8bf 26048b273c8b4800 7c8b48ff670fa3e8 0e16e826048b0824 0f0ee826048bff69 ee8948f78948ff67 
> 00000001009cce28: 90004d8b241c8948 50b848ff6bef21e8 9000000000010531 df8948ff63626be8 25048b4864f38948 28468948000000d8 
> 00000001009cce58: de8948ff647717e8 894890ff67249be8 ede81024748b48f3 85e8de8948ff6364 cccccccc90ff6724 8bfe8948f38948cf 
> 00000001009cce88: ffffffe0b848260c 480114ffffffffff 67b8c189c389de89 c1c889e9f7666666 89c2011fe8c104fa c82928c96bd189d8 
> 00000001009cceb8: 08768b48137fc085 1776084639d8f748 48c35b10c6748b48 127608463908768b 48c35b10c6748b48 000001009ccec6b8 
> 00000001009ccee8: 009cced6b848f400 ccccccf400000001 cccccccccccccccc 8b4840ec83485553 854820408b483846 4800000213840fc0 
> 00000001009ccf18: 4de838768b48f389 05e8f58948000002 8948c18948ff75bb 314830244c8948d8 44894838708b48db 0c8b20768b480824 
> 00000001009ccf48: e8ffff43e1e89026 24548b48ff63622c 89480824448b4830 244c8948ee8948f1 0093e910768b4828 8948304e8b480000 
> 00000001009ccf78: 8948d58948382474 8948cd2948302454 0c8b0824448948c6 48ffe4d635e89020 d53948d88948c289 480774c08548737c 
> 00000001009ccfa8: b84826eb38245c8b 00000000011df298 f38948ff6360f3e8 5c8948ff66b3dbe8 481024448b481024 48df894838245c8b 
> Loaded modules:
> (* denotes the module causing the exception)
> 0x400000-0x411037  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/bin/java
> 0x3a5dc00000-0x3a5dc0eff9  /lib64/tls/libpthread.so.0
> 0x3a5d400000-0x3a5d48459b  /lib64/tls/libm.so.6
> 0x3a5cf00000-0x3a5cf01c73  /lib64/libdl.so.2
> 0x3a5d100000-0x3a5d22ac59  /lib64/tls/libc.so.6
> 0x3a5cd00000-0x3a5cd1434f  /lib64/ld-linux-x86-64.so.2
> 0x2a95588000-0x2a957a660f  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit/libjvm.so
> 0x2a959e3000-0x2a959ecf13  /lib64/libnss_files.so.2
> 0x2a96c6f000-0x2a96c93473  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libjava.so
> 0x2a96d99000-0x2a96da5627  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libverify.so
> 0x3a62e00000-0x3a62e134eb  /lib64/libnsl.so.1
> 0x2a99d9f000-0x2a99db3fcf  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libnet.so
> 0x2a99eb6000-0x2a99ebed33  /lib64/libnss_nis.so.2
> 0x2a99fc0000-0x2a99fc38a3  /lib64/libnss_dns.so.2
> 0x3a5e200000-0x3a5e210d9b  /lib64/libresolv.so.2
> 0x2a9b5c8000-0x2a9b5c897b  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/librmi.so
> "RMI TCP Connection(4)-192.168.7" id=149 idx=0xc8 tid=1088993632 lastJavaFrame=(nil)
> Thread Stack Trace:
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Extended, platform specific info:
> libc release: 2.3.4-stable
> Elf headers:
> libc       ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5d11c4a0 PHOFF: 0x40 SHOFF: 0x13d5a8 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 69 STIDX: 66
> libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5dc05620 PHOFF: 0x40 SHOFF: 0x12980 EF: 0x0 HS: 64 PS: 56 PHN; 9 SS: 64 SHN: 38 STIDX: 35
> libjvm     ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x36c80 PHOFF: 0x40 SHOFF: 0x3106f0 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
> ===== END DUMP ===============================================================

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:54:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 05:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2086) Transform some
 Managed Objects in SMO
Message-ID: <30281155.1158573241292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2086?page=all ]

Dimitris Andreadis updated JBAS-2086:
-------------------------------------

       Issue Type: Feature Request  (was: Patch)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

we need to properly evaluate this change

> Transform some Managed Objects in SMO
> -------------------------------------
>
>                 Key: JBAS-2086
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2086
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final,  JBossAS-4.0.3RC1
>         Environment: jmx, twiddle
>            Reporter: Fabiano C. de Oliveira
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: management.patch
>
>
> Make managed objects that inherits from J2EEDeployedObject a SMO. The exception is WebModule and ServiceModule for a while. 
> To prevent copy&paste pattern and duplicate code the StateManagement code was moved to ManagedObject class. Instead initialize states using ServiceMBean ServiceContext was used(Adrian advice). This form MBeans tha not implement ServiceMBean not launch a exception. Tested using jmx-console and trace logs only.
> Some managed object still are not a SMO, but it is not difficult to change this.
> Suggestions always appreciated.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:05:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2008) web console
 statistics view does not show properly in Firefox
Message-ID: <1363669.1158573901291.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2008?page=all ]

Dimitris Andreadis updated JBAS-2008:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> web console statistics view does not show properly in Firefox
> -------------------------------------------------------------
>
>                 Key: JBAS-2008
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2008
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Firefox
>            Reporter: Kevin Barfield
>            Priority: Minor
>
> The statistics view in the web console has a box though it when viewed through the Firefox browser.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:09:55 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:09:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1979) Wrong resolve
 LinkRef when dereference partial result
Message-ID: <6689871.1158574195935.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1979?page=all ]

Dimitris Andreadis updated JBAS-1979:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> Wrong resolve LinkRef  when dereference partial result
> ------------------------------------------------------
>
>                 Key: JBAS-1979
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1979
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-3.2.6 Final
>         Environment: Windows 2000
>            Reporter: Boris Stepchenko
>            Priority: Minor
>
> When dereference LinkRef  in partial result used "new InitialContex()", but not "new InitialContex(refEnv)"
> So if I bind LinkRef  to url "dir1/dir2/link"
> I have different result in 2 next code
> 1.
> Contexct ctx=new InitialContext(refEnv);
> Object obj=((Context)ctx.lookup("dir1/dir2/link")).lookup("value");
> and 2.
> Contexct ctx=new InitialContext(refEnv);
> Object obj=ctx.lookup("dir1/dir2/link/value");

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:09:56 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <973004.1158574196094.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Who's maintaining the webconsole?

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:09:56 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <30449371.1158574196215.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Comment: was deleted

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:16:54 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:16:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1703) inspectMBean.jsp
 throws AccessControlException
Message-ID: <10665721.1158574614922.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1703?page=all ]

Dimitris Andreadis updated JBAS-1703:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> inspectMBean.jsp throws AccessControlException
> ----------------------------------------------
>
>                 Key: JBAS-1703
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1703
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions:  JBossAS-4.0.2RC1
>         Environment: JBoss Version 4.0.2RC1 
>            Reporter: Roland R?z
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The inspectMBean.jsp page throws a AccessControlException (javax.management.MBeanServerPermission is
> missing) although the codesource from where the JSP servlet is loaded (I use precompiled JSPs) has those
> permission.
> This is the code section where the AccessControlException is thrown
>   for(int a = 0; a < attributeInfo.length; a ++)
>    {
>       final MBeanAttributeInfo attrInfo = attributeInfo[a];
>       String attrName = attrInfo.getName();
>       String attrType = attrInfo.getType();
>       AttrResultInfo attrResult = Server.getMBeanAttributeResultInfo(objectNameString, attrInfo);
> ...
> You should use AccessController.doPrivileged to execute the code 
> AttrResultInfo attrResult = Server.getMBeanAttributeResultInfo(objectNameString, attrInfo);
> Regards

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:18:57 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1608) Configuration (RW)
 attribute on JMX-Console breaks for jboss:service=Mail MBean
Message-ID: <13298475.1158574737137.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1608?page=all ]

Dimitris Andreadis updated JBAS-1608:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Defer minor issues for now, unless Amit you want to provide a patch.

> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-1608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1608
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.0 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,  JBossAS-4.0.2RC1
>         Environment: Nothing specific
>            Reporter: Amit Bhayani
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz at nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:18:57 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 18 Sep 2006 06:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-499) Rule not rendering
 activation group correctly
Message-ID: <18329106.1158574737302.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule not rendering activation group correctly
---------------------------------------------

                 Key: JBRULES-499
                 URL: http://jira.jboss.com/jira/browse/JBRULES-499
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Decision tables
    Affects Versions: 3.0.4
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:20:53 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:20:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15228601.1158574853987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3651?page=all ]

Dimitris Andreadis updated JBAS-3651:
-------------------------------------

    Assignee: Dimitris Andreadis
    Priority: Critical  (was: Major)

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:20:54 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:20:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3611) Get the
 jboss-4.0-testsuite-sun-1.5 passing
In-Reply-To: <20914255.1157137303968.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3148282.1158574854119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3611?page=all ]

Dimitris Andreadis reassigned JBAS-3611:
----------------------------------------

    Assignee: Dimitris Andreadis

> Get the jboss-4.0-testsuite-sun-1.5 passing
> -------------------------------------------
>
>                 Key: JBAS-3611
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3611
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task for sun jdk1.5 test run failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:22:53 2006
From: jira-events at jboss.com (Amit Bhayani (JIRA))
Date: Mon, 18 Sep 2006 06:22:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-1608) Configuration (RW)
 attribute on JMX-Console breaks for jboss:service=Mail MBean
Message-ID: <4453709.1158574973706.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1608?page=all ]

Amit Bhayani reassigned JBAS-1608:
----------------------------------

    Assignee: Amit Bhayani

> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-1608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1608
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.0 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,  JBossAS-4.0.2RC1
>         Environment: Nothing specific
>            Reporter: Amit Bhayani
>         Assigned To: Amit Bhayani
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz at nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:22:53 2006
From: jira-events at jboss.com (Amit Bhayani (JIRA))
Date: Mon, 18 Sep 2006 06:22:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1608) Configuration (RW)
 attribute on JMX-Console breaks for jboss:service=Mail MBean
Message-ID: <3231291.1158574973878.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1608?page=comments#action_12343461 ] 
            
Amit Bhayani commented on JBAS-1608:
------------------------------------

Will take a look at this latter. 

> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-1608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1608
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.0 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,  JBossAS-4.0.2RC1
>         Environment: Nothing specific
>            Reporter: Amit Bhayani
>         Assigned To: Amit Bhayani
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz at nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:24:53 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:24:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3598) Get the 4.0.5.GA
 testsuite-1.4 (JRockit) passing
In-Reply-To: <31303322.1157127343880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18852490.1158575093552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3598?page=all ]

Dimitris Andreadis reassigned JBAS-3598:
----------------------------------------

    Assignee: Dimitris Andreadis

> 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
>         Assigned To: 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

        


From jira-events at jboss.com  Mon Sep 18 06:24:53 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:24:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.5.GA
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25982821.1158575093671.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis reassigned JBAS-3437:
----------------------------------------

    Assignee: Dimitris Andreadis

> Get the 3.2-compatibility tests passing for 4.0.5.GA
> ----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2037) Bug in the JBoss
	HTML adaptor.
Message-ID: <15858138.1158576421481.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2037?page=all ]

Dimitris Andreadis updated JBAS-2037:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Bug in the JBoss HTML adaptor.
> ------------------------------
>
>                 Key: JBAS-2037
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-3.2.5 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1,  JBossAS-4.0.3RC1
>            Reporter: jean deruelle
>             Fix For: JBossAS-4.0.6.CR1
>
>
> "The set of characters in a value is also limited. If
> special characters may occur, it is recommended that the
> value be quoted, using ObjectName.quote. If the value for a
> given key is sometimes quoted, then it should always be
> quoted. By default, if a value is a string (rather than a
> number, say), then it should be quoted unless you are sure
> that it will never contain special characters." quoted from
> java management best practices (see
> http://java.sun.com/products/JavaManagement/best-practices.html#mozTocId654884
> in section ObjectNameSyntax)
> When a JMX value is quoted, it causes problems to invoke methods through thr Jboss jmx web console :
> So my feeling is that the problem comes from the jboss jmx
> console jsp pages.
> The thing is that the quotes in the jmx object name are not
> encoded to the html format in the jsp pages and so the first
> opening quote is interpreted as the final quote of the html
> field.
> Here is a quick fix for Jboss-3.2.6 :
> Add the following lines to
> %JBOSS_HOME%\server\all\deploy\jmx-console.war\inspectMBean.jsp
> after line 141
> <%objectNameString=objectNameString.replaceAll("\"","&quot;");
> //objectNameString=URLEncoder.encode(objectNameString);%>
> It was a quick fix to fit my needs but the
> line should really be the one commented but in that case the
> HtmlAdaptorServlet from Jboss cannot handle it correctly
> because it doesn't do a URLDecoder.decode of the
> objectNameString stored in the request parameter called "name".
> But I might be wrong here in saying that it comes from
> jboss, maybe I missed something along the way. 
> Can someone confirm this bug or help me out there ?
> Thx
> Best regards
> Jean

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:49:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Mon, 18 Sep 2006 06:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3187) Improve web-console
	logging
Message-ID: <15190310.1158576541222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3187?page=all ]

Darran Lofthouse updated JBAS-3187:
-----------------------------------

    Component/s: Web Console
                     (was: Management services)

> Improve web-console logging
> ---------------------------
>
>                 Key: JBAS-3187
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3187
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console application has been implemented so that it is not strictly dependent on the components that it makes available in the tree.
> On initialisation if there are any errors initialising the viewer for any components in the tree view an error is output but the component is not added to the tree and the remaining components are initialised correctly.  The web-console continues to work correctly for the components that were correctly initialised with no negative effects from the components that failed to initialise.
> The web-console does not make use of Log4j at the moment.
> The web-console should be updated to use Log4j (Being careful with classes sent to the applet) and the initialisation failures should be logged at a low  level (either DEBUG or even TRACE).  This will allow the web-console to be installed in more configurations without as many dependencies.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:51:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1748) hot deploying JMX
 invoker service fails
Message-ID: <11418960.1158576661750.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1748?page=all ]

Dimitris Andreadis updated JBAS-1748:
-------------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

> hot deploying JMX invoker service fails
> ---------------------------------------
>
>                 Key: JBAS-1748
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1748
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Norman Richards
>         Assigned To: Vicky Kak
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.CR1
>
>
> jmx-invoker-service.xml cannot be hot deployed.  Trying to hot deploy it causes a failure when redeploying the web console.  After this failure, I the JMX invoker cannot be contacted.  Here's the resulting web console error:
> 22:49:04,904 ERROR [WebModule] Starting failed jboss.web.deployment:id=-1500951031,war=web-console.war
> java.lang.NullPointerException
>         at org.jboss.web.WebModule.startModule(WebModule.java:67)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:911)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:416)
>         at org.jboss.system.ServiceController.start(ServiceController.java:438)
>         at org.jboss.system.ServiceController.start(ServiceController.java:438)
>         at org.jboss.system.ServiceController.start(ServiceController.java:438)
>         at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:273)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:964)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
>         at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy8.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:483)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:215)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:194)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:51:02 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2477) Exception in
 web-console j2ee domain after undeploy of application
Message-ID: <13220918.1158576662308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2477?page=all ]

Dimitris Andreadis updated JBAS-2477:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse

> Exception in web-console j2ee domain after undeploy of application
> ------------------------------------------------------------------
>
>                 Key: JBAS-2477
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2477
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Both Linux and Windows
>            Reporter: Lennart Petersson
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Had listed all apps in web-console j2ee domains. Then undeployed one app. Then list again in web-console ---> exception below.
> 10:31:54,896 INFO  [TomcatDeployer] undeploy, ctxPath=/crimeportal, warUrl=.../tmp/deploy/tmp65013crimeportal.war/
> 10:31:54,914 INFO  [EJBDeployer] Undeploying: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/CrimePortalBeans.jar
> 10:31:55,162 INFO  [ProxyFactory] Unbind EJB Home 'SicilianLaundry' from jndi 'SicilianLaundry'
> 10:31:55,172 INFO  [EjbModule] Undeployed SicilianLaundry
> 10:31:55,173 INFO  [ProxyFactory] Unbind EJB Home 'ShanghaiLaundry' from jndi 'ShanghaiLaundry'
> 10:31:55,173 INFO  [EjbModule] Undeployed ShanghaiLaundry
> 10:31:55,190 INFO  [EARDeployer] Undeploying J2EE application, destroy step: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/
> 10:32:01,401 INFO  [STDOUT] javax.management.InstanceNotFoundException: jboss.management.local:J2EEApplication=CrimePortal.ear,J2EEServer=Local,j2eeType=EJBModule,name=CrimePortalBeans.jar is not registered.
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:651)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDeployedObjects(JSR77Lister.java:167)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServer(JSR77Lister.java:194)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServers(JSR77Lister.java:218)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomain(JSR77Lister.java:233)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomains(JSR77Lister.java:256)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.getTreeForResource(JSR77Lister.java:282)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.helpers.AbstractPluginWrapper.getSubTreeForResource(AbstractPluginWrapper.java:201)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreesForResource(PluginManager.java:392)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreeForProfile(PluginManager.java:192)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:32:01,411 INFO  [STDOUT]     at java.lang.reflect.Method.invoke(Method.java:324)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.processRequest(InvokerServlet.java:90)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.doPost(InvokerServlet.java:133)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 10:32:01,430 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:534)
> 1

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3188) Reduce the
 dependencies specified
 by web-console so it can be installed in more profiles.
Message-ID: <1978046.1158577021368.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3188?page=all ]

Dimitris Andreadis updated JBAS-3188:
-------------------------------------

    Component/s: Web Console
                     (was: Installer)

> Reduce the dependencies specified by web-console so it can be installed in more profiles.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-3188
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3188
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console has been implemented to it is not strictly dependent on the components it makes available through it's interface, if any component it makes available through the interface is not installed then initialisation will fail just for that component and it will not be added to the tree.  The remaining components will still be added to the tree and the web-console will continue to work correctly.
> The installer should be updated so the web-console is dependent on less components so it can be installed in more profiles.
> This will also get rid of another problem where the web console is dependent on specifc versions of components e.g. At the moment it is dependent on the JDK 1.4 version of AOP so can not be installed in any profile that uses the JDK 5.0 version of AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2008) web console
 statistics view does not show properly in Firefox
Message-ID: <20554802.1158577021559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2008?page=all ]

Dimitris Andreadis updated JBAS-2008:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse

> web console statistics view does not show properly in Firefox
> -------------------------------------------------------------
>
>                 Key: JBAS-2008
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2008
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Firefox
>            Reporter: Kevin Barfield
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>
> The statistics view in the web console has a box though it when viewed through the Firefox browser.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <617409.1158577021735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3402) Web Console and
	Firefox
In-Reply-To: <5847131.1153247531914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5794340.1158577141594.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3402?page=all ]

Dimitris Andreadis updated JBAS-3402:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse  (was: Dimitris Andreadis)

> Web Console and Firefox
> -----------------------
>
>                 Key: JBAS-3402
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3402
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: MS W2000 SP4
>            Reporter: Vladimir Gendler
>         Assigned To: Darran Lofthouse
>         Attachments: Snapshots.zip
>
>
> Web Console output in Mozilla Firefox (and Seamonkey)
> is messed up. Compare the attached archive with
> snapshots from Mozilla Firefox and MSIE.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2008) web console
 statistics view does not show properly in Firefox
Message-ID: <24160531.1158577141757.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2008?page=all ]

Dimitris Andreadis updated JBAS-2008:
-------------------------------------

    Comment: was deleted

> web console statistics view does not show properly in Firefox
> -------------------------------------------------------------
>
>                 Key: JBAS-2008
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2008
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Firefox
>            Reporter: Kevin Barfield
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>
> The statistics view in the web console has a box though it when viewed through the Firefox browser.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <8931821.1158577141913.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Comment: was deleted

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:07:01 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 18 Sep 2006 07:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-499) Rule not
 rendering activation group correctly
In-Reply-To: <18329106.1158574737302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14239661.1158577621346.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-499?page=all ]

Michael Neale resolved JBRULES-499.
-----------------------------------

    Fix Version/s: 3.0.5
                   3.1-m1
       Resolution: Done

> Rule not rendering activation group correctly
> ---------------------------------------------
>
>                 Key: JBRULES-499
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-499
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 3.0.5, 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:13:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2131) Better support for
 BMT SFSB "mistakes"
Message-ID: <18651459.1158577981428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2131?page=all ]

Dimitris Andreadis updated JBAS-2131:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Weston Price

Weston, do you want to have a go with this, for the next release?

> Better support for BMT SFSB "mistakes"
> --------------------------------------
>
>                 Key: JBAS-2131
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2131
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Further to JBAS-2128 we should also implement some sort of listener on the transaction timeout.
> Given the stupid BMT SFSB semantics (this part of the spec is one my favourite anti-patterns :-)
> where a client can hog server resources.
> sfsb.doBegin();
> doLongRunningProcess();
> sfsb.doCommit();
> And even crash during the doLongRunningProcess().
> We should allow the server to reclaim the resources from a transaction timeout more quickly.
> Another option would be to allow a configuration that does a rollback() at transaction timeout.
> But this would require some serious testing to make sure all JBoss code is checking transaction status correctly.
> It would also confuse any non-j2ee compliant framework that registers transaction synchronizations
> and then assumes their "thread local" is still valid from the timeout thread or they aren't threadsafe. 
> No names mentioned to protect the guilty :-)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:15:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2037) Bug in the JBoss
	HTML adaptor.
Message-ID: <31884569.1158578101361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2037?page=all ]

Dimitris Andreadis reassigned JBAS-2037:
----------------------------------------

    Assignee: Amit Bhayani

Amit, more jmx-console stuff, if you want to have a look.

> Bug in the JBoss HTML adaptor.
> ------------------------------
>
>                 Key: JBAS-2037
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-3.2.5 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1,  JBossAS-4.0.3RC1
>            Reporter: jean deruelle
>         Assigned To: Amit Bhayani
>             Fix For: JBossAS-4.0.6.CR1
>
>
> "The set of characters in a value is also limited. If
> special characters may occur, it is recommended that the
> value be quoted, using ObjectName.quote. If the value for a
> given key is sometimes quoted, then it should always be
> quoted. By default, if a value is a string (rather than a
> number, say), then it should be quoted unless you are sure
> that it will never contain special characters." quoted from
> java management best practices (see
> http://java.sun.com/products/JavaManagement/best-practices.html#mozTocId654884
> in section ObjectNameSyntax)
> When a JMX value is quoted, it causes problems to invoke methods through thr Jboss jmx web console :
> So my feeling is that the problem comes from the jboss jmx
> console jsp pages.
> The thing is that the quotes in the jmx object name are not
> encoded to the html format in the jsp pages and so the first
> opening quote is interpreted as the final quote of the html
> field.
> Here is a quick fix for Jboss-3.2.6 :
> Add the following lines to
> %JBOSS_HOME%\server\all\deploy\jmx-console.war\inspectMBean.jsp
> after line 141
> <%objectNameString=objectNameString.replaceAll("\"","&quot;");
> //objectNameString=URLEncoder.encode(objectNameString);%>
> It was a quick fix to fit my needs but the
> line should really be the one commented but in that case the
> HtmlAdaptorServlet from Jboss cannot handle it correctly
> because it doesn't do a URLDecoder.decode of the
> objectNameString stored in the request parameter called "name".
> But I might be wrong here in saying that it comes from
> jboss, maybe I missed something along the way. 
> Can someone confirm this bug or help me out there ?
> Thx
> Best regards
> Jean

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:17:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1984)
 HttpNamingContextFactory unable to reconnect
Message-ID: <26278841.1158578221801.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1984?page=all ]

Dimitris Andreadis updated JBAS-1984:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Tom  Elrod

Maybe Tom, can take a look at this case, for the next release.

> HttpNamingContextFactory unable to reconnect
> --------------------------------------------
>
>                 Key: JBAS-1984
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1984
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Remoting
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: XP
>            Reporter: Bernd Eckenfels
>         Assigned To: Tom  Elrod
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this:
> ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568)
> 	at net.eckenfels.JNDITest.main(JNDITest.java:72)
> Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348)
> 	... 3 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224)
> 	... 4 more
> Caused by: java.net.UnknownHostException: http: http
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1061)
> 	at java.net.InetAddress.getByName(InetAddress.java:958)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220)
> 	... 4 more
> Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct:
> 		p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory");
> 		p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory");
> 		p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> 		p.put("jnp.disableDiscovery", "true");
>                Context rootCtx = (Context)new InitialContext(p);
> 		while(true)
> 		{
> 			try
> 			{
> 			// rootCtx = new InitialContext(p);
> 			Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi");
> 			l = jmxCtx.list("");
> 			while(l.hasMore())
> 			{
> 				System.out.println(" - " + l.next());
> 			}
> 			} catch (Throwable t) {
> 				System.out.println("ex: " + t); t.printStackTrace(System.out);
> 			}
> 			try{Thread.sleep(10000);}catch(Throwable t) { }
> 		}
> This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling.
> The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:21:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1728)
 Statement.getConnection not working for remote client
Message-ID: <11023182.1158578461884.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1728?page=all ]

Dimitris Andreadis updated JBAS-1728:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Weston Price

> Statement.getConnection not working for remote client
> -----------------------------------------------------
>
>                 Key: JBAS-1728
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1728
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> the org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService is not handling Statement.getConnection. It returns the real thing instead of a proxy --> Serialization exception!!.
> This is related to JBAS-1678.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:21:02 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1728)
 Statement.getConnection not working for remote client
Message-ID: <9652902.1158578462104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1728?page=all ]

Dimitris Andreadis updated JBAS-1728:
-------------------------------------

    Component/s: JCA service
                     (was: Remoting)

> Statement.getConnection not working for remote client
> -----------------------------------------------------
>
>                 Key: JBAS-1728
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1728
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> the org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService is not handling Statement.getConnection. It returns the real thing instead of a proxy --> Serialization exception!!.
> This is related to JBAS-1678.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:33:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-2398) Check for
 unparameterized interface configuration
Message-ID: <13843010.1158579181244.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2398?page=all ]

Dimitris Andreadis resolved JBAS-2398.
--------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

>From my tests (detailed in the forum post), using -b correctly binds the various ports. Only the jgroups stack may present a different behavior but the clustering team seems satisfied, or else somebody else can take it from here.

> Check for unparameterized interface configuration
> -------------------------------------------------
>
>                 Key: JBAS-2398
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2398
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Make sure all interface configuration distributed with JBossAS uses the
> ${jboss.bind.address:0.0.0.0} pattern to pickup the standard system property.
> But be careful that 0.0.0.0 does not end up as a connection address for a client.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:35:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2193) abstract schema name
 with word limit in name
Message-ID: <31607242.1158579301372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ]

Dimitris Andreadis updated JBAS-2193:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> abstract schema name with word limit in name
> --------------------------------------------
>
>                 Key: JBAS-2193
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2193
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions:  JBossAS-4.0.3RC1
>         Environment: OS: Windows XP and FreeBsd
> Database: PostgreSQL 7.4
>            Reporter: Yura Kravchuk
>         Assigned To: Alexey Loubyansky
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly.
> Herewith exception:
> 17:02:28,671 INFO  [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ
> ory; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.
> Was expecting:
>     "FROM" ...
>     ; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:43:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3272) update JBossRemoting
 to version 2.0.0
Message-ID: <5729459.1158579781301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3272?page=all ]

Dimitris Andreadis updated JBAS-3272:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

We won't upgrade remoting for jboss 4.0.5.GA, since jbossws-1.0.4 (that work with remoting 2) will be release in Oct.

> update JBossRemoting to version 2.0.0
> -------------------------------------
>
>                 Key: JBAS-3272
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3272
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Need to update JBossAS to include jboss-remoting.jar for version 2.0.0.GA of JBossRemoting.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:45:01 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 18 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-500) Special connective
 "or" constraint
Message-ID: <11735537.1158579901241.JavaMail.jira@cloud.prod.atl2.jboss.com>

Special connective "or" constraint
----------------------------------

                 Key: JBRULES-500
                 URL: http://jira.jboss.com/jira/browse/JBRULES-500
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo, Rule Assemply/SPI
            Reporter: Michael Neale
         Assigned To: Mark Proctor


Would be nice to have some construct like

Person(address == null or age < 30)

which would kind of short circuit (ideally). Could be done as a special thing with alpha nodes, or another type of join node, or something else. 

This is a common problem to have for users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1182) Thread creation
 during deactivate_object
Message-ID: <21614621.1158580141378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1182?page=all ]

Dimitris Andreadis updated JBAS-1182:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

I still don't see any progress in the jacorb bugzilla

> Thread creation during deactivate_object
> ----------------------------------------
>
>                 Key: JBAS-1182
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1182
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>            Reporter: SourceForge User
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: kevinconner .
> This is a duplicate of bug 527 in the JacORB database.
>  It is being submitted here so that a patch may be
> applied to the JBoss patched version of JacORB.
> http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527
> The deactiviation of an object causes Thread creation
> in AOM.remove.  Would it
> be possible to use a thread pool instead of creating
> new threads?
> A possible solution could be to have the
> RequestController provide a
> notification mechanism (instead of a thread waiting on
> object completion) and
> have the notification request work from the thread pool.
> The attached patch uses a threadpool to prevent the
> thread creation but I don't
> believe it is the best solution.
> Index: AOM.java
> ===================================================================
> RCS file:
> /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v
> retrieving revision 1.29
> diff -u -r1.29 AOM.java
> --- AOM.java	6 May 2004 12:40:00 -0000	1.29
> +++ AOM.java	21 Oct 2004 14:38:11 -0000
> @@ -27,6 +27,9 @@
>  import org.jacorb.poa.util.ByteArrayKey;
>  import org.jacorb.poa.util.POAUtil;
>  import org.jacorb.poa.util.StringPair;
> +import org.jacorb.util.threadpool.Consumer;
> +import org.jacorb.util.threadpool.ConsumerFactory;
> +import org.jacorb.util.threadpool.ThreadPool;
>  
>  import
> org.omg.PortableServer.POAPackage.ObjectAlreadyActive;
>  import org.omg.PortableServer.POAPackage.ObjectNotActive;
> @@ -69,6 +72,23 @@
>      /** a lock to protect two consecutive operations
> on the list, used
>          in remove() */
>      private Object              deactivationListLock =
> new Object();
> +    
> +    private Consumer deactivationConsumer = new
> Consumer() {
> +        public void doWork(final Object job) {
> +            try {
> +                ((Runnable)job).run() ;
> +            } catch (final Throwable th) {
> +                logger.info("Unhandled exception
> during deactivation", th);
> +            }
> +        } 
> +    } ;
> +    private ConsumerFactory
> deactivationConsumerFactory = new ConsumerFactory() {
> +        public Consumer create() {
> +            return deactivationConsumer ;
> +        }
> +    } ;
> +    
> +    private ThreadPool deactivationPool = new
> ThreadPool(deactivationConsumerFactory) ;
>  
>      private AOM()
>      {
> @@ -348,8 +368,7 @@
>          final POA poa_ = poa;
>          final boolean cleanupInProgress_ =
> cleanupInProgress;
>  
> -        Thread thread = new Thread("AOM_RemovalThread")
> -        {
> +        final Runnable job = new Runnable() {
>              public void run()
>              {
>                  _remove(
> @@ -361,8 +380,8 @@
>                         );
>              }
>          };
> -
> -        thread.start();
> +        
> +        deactivationPool.putJob(job) ;
>      }

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1180) bi-pass JacORB
 interceptors for purely local invocations
Message-ID: <27637992.1158580141622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1180?page=all ]

Dimitris Andreadis updated JBAS-1180:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

I still don't see any progress in the jacorb bugzilla

> bi-pass JacORB interceptors for purely local invocations
> --------------------------------------------------------
>
>                 Key: JBAS-1180
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1180
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-3.2.6 Final
>            Reporter: SourceForge User
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: marklittle .
> I registered the following issue 
> (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?
> id=526) with JacORB bugzilla a couple of weeks ago, but 
> no response so far. I think it's sufficiently important to 
> register here too in case you are able to do something 
> for JBoss.
> In the current implementation of JacORB (2.2), if I 
> register an interceptor with the ORB, then 
> it appears that all invocations to all objects go through 
> that interceptor, 
> even if they are co-located with the invoker. I 
> understand that rational given 
> the PI specification and the original intention behind 
> that work: to make 
> local invocations and remote invocations similar.
> However, most ORBs provide a way of doing a local, no-
> interceptor 
> optimization. The JDK 1.4 ORB is one example (though 
> that takes the other 
> extreme and won't invoke interceptors on any local 
> object).
> Orbix 2000, for example, supports multiple ORBs and 
> POAs within the same VM, 
> and interceptors are registered on a per-ORB basis, not 
> a per VM basis as 
> appears to be the case with JacORB. You can also turn 
> on local optimizations 
> for the individual ORBs.
> The reason for asking for this optimization is 
> performance. With a very simple 
> test, where the interceptor does nothing, we see a 66% 
> degredation in 
> performance for local calls. For example, with no 
> interceptors we can get > 3000 invocations, whereas 
> with a "null" interceptor this is around 1000.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:51:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2057) Need an EJB3 mbean
	JSR-77 mapping
Message-ID: <4848692.1158580261406.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2057?page=all ]

Dimitris Andreadis updated JBAS-2057:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Need an EJB3 mbean JSR-77 mapping
> ---------------------------------
>
>                 Key: JBAS-2057
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2057
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just work.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-1941) JBoss-4.0.1Sp1
 startup slow (server hangs in SQLUtil.tableExists() method)
Message-ID: <9308878.1158580621354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1941?page=all ]

Dimitris Andreadis resolved JBAS-1941.
--------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Cannot Reproduce Bug

I've closing this, if it cannot be reproduced by Alexey.

> JBoss-4.0.1Sp1 startup slow (server hangs in SQLUtil.tableExists() method)
> --------------------------------------------------------------------------
>
>                 Key: JBAS-1941
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1941
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.1 SP1
>         Environment: Effect takes place on the Solaris (SunOS Release 5.8) as well as the Windows (XP) Platform. The System uses a DB2 Database (UDB Runtime Client V8.1 connects via DB2Connect to DB2 Server V7.0 running on OS390)
> I observed the same Effect on other JBoss releases (JBoss-3.2.5, JBoss-4.0.2)
>            Reporter: helly15
>         Assigned To: Alexey Loubyansky
>         Attachments: JBoss4_Startup 2005-06-21 17-59-35.profile
>
>
> I am moving from JBoss-3.2.1 to JBoss-4.0.1Sp1. The problem  I am facing is that it takes JBoss-4.0.1 over 10 minutes  to start,  while JBoss-3.2.1 started up in under 3 minutes. 
> I did a profiling of the startup process using the Eclipse Profiler.  The profiling revealed that the server spends nearly 10 seconds in the method SQLUtil.tableExists()  every time the method is called during the startup process. This method is called once for every table that exists in the application (32 tables). This leads to the lengthy startup time.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:29:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 08:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3625) Update EJB3 for
	jboss-4.0.5.GA
In-Reply-To: <13328214.1157537614191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1488013.1158582541246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3625?page=all ]

Dimitris Andreadis closed JBAS-3625.
------------------------------------

    Resolution: Done

> Update EJB3 for jboss-4.0.5.GA
> ------------------------------
>
>                 Key: JBAS-3625
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3625
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> Merge EJB3 changes to Branch_4_0, take care of any library dependency issues (e.g. new remoting version required?)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:33:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 18 Sep 2006 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-702) Quartz Timer
 Service in E-EJB3 hangs process, exception on shutdown
In-Reply-To: <1150389.1158281915419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32865892.1158582781249.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-702?page=comments#action_12343472 ] 
            
Carlo de Wolf commented on EJBTHREE-702:
----------------------------------------

     [java] java.lang.NullPointerException
     [java]     at javax.naming.InitialContext.getURLScheme(InitialContext.java:228)
     [java]     at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:277)
     [java]     at javax.naming.InitialContext.lookup(InitialContext.java:351)
     [java]     at org.quartz.utils.JNDIConnectionProvider.init(JNDIConnectionProvider.java:127)
     [java]     at org.quartz.utils.JNDIConnectionProvider.<init>(JNDIConnectionProvider.java:86)
     [java]     at org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory.setDataSource(QuartzTimerServiceFactory.java:220)


> Quartz Timer Service in E-EJB3 hangs process, exception on shutdown
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-702
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-702
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> to test this out:
> build embedded.dist
> go run one of the tutorials.  You will see that the applicatoin will never exit.  I'm guessing this is becuase a Quartz thread is a non-daemon thread and holding up the exit of the process.  Also there is a NullPointerException on shutdown.  I have disabled the Quartz Timer Service in embedded-jboss-beans.xml for now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:57:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Mon, 18 Sep 2006 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-285) overridden method
 super calls do not get intercepted with generated advisors
In-Reply-To: <19742940.1158252037003.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <258960.1158584221265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-285?page=all ]

Kabir Khan updated JBAOP-285:
-----------------------------

    Summary: overridden method super calls do not get intercepted with generated advisors  (was: overloaded method super calls do not get intercepted with generated advisors)

> overridden method super calls do not get intercepted with generated advisors
> ----------------------------------------------------------------------------
>
>                 Key: JBAOP-285
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-285
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> class Base{
>    void superCall(){}
> }
> class Sub extends Base{
>    void superCall(){super.superCall();}
> }
> <bind pointcut="execution(* $instanceof{Base}->superCall())">
>    <interceptor class="X"/>
> </bind>
> Sub sub = new Sub();
> sub.superCall();
> We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. 
> I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:57:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Mon, 18 Sep 2006 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-285) overridden method
 super calls do not get intercepted with generated advisors
In-Reply-To: <19742940.1158252037003.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22086361.1158584221393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-285?page=all ]

Kabir Khan closed JBAOP-285.
----------------------------

    Resolution: Done

> overridden method super calls do not get intercepted with generated advisors
> ----------------------------------------------------------------------------
>
>                 Key: JBAOP-285
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-285
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> class Base{
>    void superCall(){}
> }
> class Sub extends Base{
>    void superCall(){super.superCall();}
> }
> <bind pointcut="execution(* $instanceof{Base}->superCall())">
>    <interceptor class="X"/>
> </bind>
> Sub sub = new Sub();
> sub.superCall();
> We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. 
> I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:40:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3665) Update JBoss
	Serialization
Message-ID: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Serialization
--------------------------

                 Key: JBAS-3665
                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
            Priority: Critical
             Fix For: JBossAS-4.0.5.GA


There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:40:01 2006
From: jira-events at jboss.com (Mladen Turk (JIRA))
Date: Mon, 18 Sep 2006 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17259519.1158586801349.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343476 ] 
            
Mladen Turk commented on JBAS-3495:
-----------------------------------

Actually we have the service wrapper that allows to run any .bat script as a service.
It even works on WIN32, WIN64/AMD64 and WIN64/IA64 natively.

The code is part of JBossWeb build and is part of JBossWeb binary distribution (.zip)
New code is at:
http://anonsvn.jboss.org/repos/jbossnative/trunk/utils/windows/native/service/jbosssvc/


> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:40:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
In-Reply-To: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16857595.1158586801515.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-89?page=all ]

Clebert Suconic updated JBSER-89:
---------------------------------

    Fix Version/s: 1.0.3 GA

> StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSER-89
>                 URL: http://jira.jboss.com/jira/browse/JBSER-89
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.1 GA, 1.0.2 GA
>            Reporter: Manik Surtani
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA
>
>
> See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:42:56 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 09:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-86) The distribution jar
 manifest contains obsolete version information
In-Reply-To: <7606513.1155111192460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22763529.1158586976078.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-86?page=all ]

Clebert Suconic updated JBSER-86:
---------------------------------

    Fix Version/s: 1.0.3 GA

> The distribution jar manifest contains obsolete version information
> -------------------------------------------------------------------
>
>                 Key: JBSER-86
>                 URL: http://jira.jboss.com/jira/browse/JBSER-86
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.2 GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.3 GA
>
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: JBoss Inc.
> version: 1.0.0.RC1
> Main-Class: org.jboss.serial.Version

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:47:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 18 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2193) abstract schema name
 with word limit in name
Message-ID: <5979431.1158587221437.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ]

Alexey Loubyansky closed JBAS-2193.
-----------------------------------

    Fix Version/s:     (was: JBossAS-4.0.6.CR1)
       Resolution: Out of Date

This one was probably fixed as a side effect of some other issue. It's working against the current Branch_4_0.
15:42:00,685 INFO  [FacadeSessionBean] RUN>
15:42:00,685 DEBUG [A#ejbSelectSelect] DYNAMIC-QL: select count(limit_a.id) from limita limit_a
15:42:00,685 DEBUG [A#ejbSelectSelect] Executing SQL: SELECT count( t0_limit_a.id) FROM A t0_limit_a
15:42:00,685 INFO  [STDOUT] [1]

> abstract schema name with word limit in name
> --------------------------------------------
>
>                 Key: JBAS-2193
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2193
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions:  JBossAS-4.0.3RC1
>         Environment: OS: Windows XP and FreeBsd
> Database: PostgreSQL 7.4
>            Reporter: Yura Kravchuk
>         Assigned To: Alexey Loubyansky
>            Priority: Minor
>
> We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly.
> Herewith exception:
> 17:02:28,671 INFO  [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ
> ory; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.
> Was expecting:
>     "FROM" ...
>     ; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:53:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-58) Add back EPR
	functionality
Message-ID: <30410377.1158587581719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-58?page=all ]

Mark Little closed JBESB-58.
----------------------------

    Resolution: Done

> Add back EPR functionality
> --------------------------
>
>                 Key: JBESB-58
>                 URL: http://jira.jboss.com/jira/browse/JBESB-58
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> Prior to Rosetta, the Alpha 1 codebase has the EPR capabilities. Add this back.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:53:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31760280.1158587581871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little updated JBESB-118:
------------------------------

    Fix Version/s: 4.0
                       (was: 4.1)

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.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

        


From jira-events at jboss.com  Mon Sep 18 09:53:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13828712.1158587582020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little updated JBESB-118:
------------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.)]

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.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

        


From jira-events at jboss.com  Mon Sep 18 09:53:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-105) Use a true UID
	implementation
In-Reply-To: <25693193.1154528711566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16145339.1158587582185.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-105?page=all ]

Mark Little updated JBESB-105:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Use a true UID implementation
> -----------------------------
>
>                 Key: JBESB-105
>                 URL: http://jira.jboss.com/jira/browse/JBESB-105
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.1
>
>
> The core code uses the notion of a UID, but seems to only use a long. If this needs to be unique, then we need to look at using a proper UID 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

        


From jira-events at jboss.com  Mon Sep 18 09:53:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-62) Change jar names
Message-ID: <31453459.1158587582337.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-62?page=all ]

Mark Little updated JBESB-62:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Change jar names
> ----------------
>
>                 Key: JBESB-62
>                 URL: http://jira.jboss.com/jira/browse/JBESB-62
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:57:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-125) Installer
In-Reply-To: <9494883.1155053112755.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14888443.1158587821619.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-125?page=all ]

Mark Little updated JBESB-125:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Installer
> ---------
>
>                 Key: JBESB-125
>                 URL: http://jira.jboss.com/jira/browse/JBESB-125
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:57:02 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Mon, 18 Sep 2006 09:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25945443.1158587822225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Sverker Abrahamsson updated JBPORTAL-998:
-----------------------------------------

    Attachment: eclipse-2.6.patch

This patch is on the 2.6 tree, the previous patch file was on the 2.4 tree.

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse-2.6.patch, eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:05:01 2006
From: jira-events at jboss.com (James Callaghan (JIRA))
Date: Mon, 18 Sep 2006 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-587) GPD crashes if
 xmlbuddy plugin is installed
Message-ID: <2109524.1158588301988.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-587?page=comments#action_12343480 ] 
            
James Callaghan commented on JBPM-587:
--------------------------------------

I don't have XML buddy either and the GDP is unusable. It just crashes as soon as I open a process. I do however have JBoss IDE 1.5.0 so that seems to be something I have in common with Carmine.

> 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: Tom Baeyens
>
> 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

        


From jira-events at jboss.com  Mon Sep 18 10:19:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3665) Update JBoss
	Serialization
In-Reply-To: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6827029.1158589141412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3665?page=all ]

Clebert Suconic reassigned JBAS-3665:
-------------------------------------

    Assignee: Clebert Suconic

> Update JBoss Serialization
> --------------------------
>
>                 Key: JBAS-3665
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:31:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1082)
 jdbc.WrapperDataSource.getConnection is slow
Message-ID: <5003799.1158589861766.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1082?page=all ]

Clebert Suconic updated JBAS-1082:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> jdbc.WrapperDataSource.getConnection is slow
> --------------------------------------------
>
>                 Key: JBAS-1082
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1082
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-3.2.6 Final
>            Reporter: Elias Ross
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: genman .
> I've been profiling JMS code.  When a JMS message is
> added to the server, the persistence manager locates an
> appropriate DataSource.
> Out of the time spent in
> org.jboss.mq.Connection.sendToServer, about 28% of the
> time is getting the database connection through 
> jdbc.WrapperDataSource.getConnection to do its work. 
> This is after the pool has been initialized, etc.  (40%
> is actual persistence, though most of it is the message
> serialization.)
> I suspect a lot of the work is calculating a hashCode
> on the javax.security.auth.Subject.  SubjectCriKey and
> SubjectKey should have this value cached.  Ideally,
> when one is accessing the local DB, none of this auth
> stuff should have to take place.  Looking at the source
> for Subject.java, the hash code is not kept.
> BaseConnectionManager2.allocateConnection %CPU=27.949
> %Time=27.963 calls=411
> Allocations I've seen:
> JBossManagedConnectionPool$SubjectActions
> is created 3284 times (for 411 getConnection calls)
> java.util.Properties (1642 times)
> (Disclaimer:  This was done through JBoss profiler,
> which may or may not create real numbers.  It does
> look, though, that CX is pretty slow for some operations.)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:35:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 18 Sep 2006 10:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3150) Cipher attribute in
 the SSL Connector is ignored
Message-ID: <31453186.1158590101716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3150?page=all ]

Anil Saldhana reassigned JBAS-3150:
-----------------------------------

    Assignee: Anil Saldhana

> Cipher attribute in the SSL Connector is ignored
> ------------------------------------------------
>
>                 Key: JBAS-3150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Security
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> Please refer to the forum thread for more information.
> Please investigate this issue.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:35:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3142) Add UnifiedInvoker
 (JBSer and JavaSer) into Version MatrixTestSuite
Message-ID: <11259369.1158590101883.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3142?page=all ]

Clebert Suconic updated JBAS-3142:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Add UnifiedInvoker (JBSer and JavaSer) into Version MatrixTestSuite
> -------------------------------------------------------------------
>
>                 Key: JBAS-3142
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3142
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:37:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1939) MBean getAttribute()
 launch NotSerializableException when invoked from a remote client
Message-ID: <15983579.1158590221429.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1939?page=all ]

Clebert Suconic updated JBAS-1939:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> MBean getAttribute() launch NotSerializableException when invoked from a remote client
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-1939
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1939
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: jmx, twiddle
>            Reporter: Fabiano C. de Oliveira
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> when executing twiddle to get attribute from some MBeans a NotSerializableException java.io.NotSerializableException is launched.
> To reproduce this just type:
> D:\jboss-4.0.2\bin>twiddle.bat get "jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/" logger 
> How can this can be fixed ? Ignoring the Non serializable attributes, returning null to Nonserializable attributes, become invisible all non-serializable attribute ?

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:39:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <10260853.1158590397597.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:41:56 2006
From: jira-events at jboss.com (James Callaghan (JIRA))
Date: Mon, 18 Sep 2006 10:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-587) GPD crashes if
 xmlbuddy plugin is installed
Message-ID: <17493905.1158590516876.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-587?page=comments#action_12343481 ] 
            
James Callaghan commented on JBPM-587:
--------------------------------------

I tried to disable the JBoss IDE features and plugins but the GDP still crashed when you opened it. I re-installed eclipse from scratch and added the jBPM plugins and features manually. After restarting Eclipse, jBPM worked fine. I suppose I'll just have to start and stop JBoss from a command prompt :(

> 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: Tom Baeyens
>
> 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

        


From jira-events at jboss.com  Mon Sep 18 11:14:56 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Mon, 18 Sep 2006 11:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-545) Transaction
 edge cases and memory leak
Message-ID: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>

Transaction edge cases and memory leak
--------------------------------------

                 Key: JBMESSAGING-545
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Tim Fox
             Fix For: 1.0.1.CR5


There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.

We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).

We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.

Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.

In this case the manager may retry the commit, but we will have no record of the branch.

Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:41:55 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 11:41:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3554) Upgrade JBoss AS
 to use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7769886.1158594115632.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3554?page=comments#action_12343482 ] 
            
Dimitris Andreadis commented on JBAS-3554:
------------------------------------------

Stan, 1.1.4 is released now, yes?

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:50:55 2006
From: jira-events at jboss.com (Adrian Pillinger (JIRA))
Date: Mon, 18 Sep 2006 11:50:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-708) Bundled
 jboss-ejb3-all.jar is invalid in embeddable container
Message-ID: <22313758.1158594655833.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bundled jboss-ejb3-all.jar is invalid in embeddable container
-------------------------------------------------------------

                 Key: EJBTHREE-708
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-708
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC9 - FD
         Environment: Linux, Maven, Java 5.
            Reporter: Adrian Pillinger
            Priority: Blocker


The classes that were bundled together to form the jboss-ejb3-all.jar of the embeddable container are not compatible.

I am calling the following code...

{code}
        EJB3StandaloneBootstrap.boot(null);
        
        Collection<URL> deployDirs = getDeployDirURLs();
        Collection<URL> persistenceArchives = getPersistenceArchiveURLs();
        
        deployer = EJB3StandaloneBootstrap.createDeployer();

        .... get deploy dirs ..

        deployer.getDeployDirs().addAll(deployDirs);
        deployer.create();
        deployer.start();
{code}

When the code gets to deployer.create(); it fails with the following stack trace

{noformat}
java.lang.NoSuchMethodError: org/jboss/ejb3/Ejb3Deployment.<init>(Lorg/jboss/ejb3/DeploymentUnit;Lorg/jboss/ejb3/EAR;)V
	at org.jboss.ejb3.embedded.EJB3StandaloneDeployment.<init>(EJB3StandaloneDeployment.java:49)
	at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.create(EJB3StandaloneDeployer.java:438)
	at com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:84)
	at com.dolby.pics.test.TestSetupWrapper.setUp(TestSetupWrapper.java:32)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.extensions.TestSetup.run(TestSetup.java:27)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
	at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
{noformat}

The error as you can see is an incompatability between 
{noformat}
org.jboss.ejb3.embedded.EJB3StandaloneDeployment 
{noformat}
and 
{noformat}
org.jboss.ejb3.Ejb3Deployment
{noformat}

I'm guessing that these are from different jars and have been bundled into the same jar without a compile any tests to check that they are compatible.

My code worked absolutely fine with alpha 8 of the embeddable container.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:52:54 2006
From: jira-events at jboss.com (Adrian Pillinger (JIRA))
Date: Mon, 18 Sep 2006 11:52:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-708) Bundled
 jboss-ejb3-all.jar is invalid in embeddable container
In-Reply-To: <22313758.1158594655833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2403725.1158594774254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-708?page=all ]

Adrian Pillinger updated EJBTHREE-708:
--------------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD

> Bundled jboss-ejb3-all.jar is invalid in embeddable container
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-708
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-708
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>         Environment: Linux, Maven, Java 5.
>            Reporter: Adrian Pillinger
>            Priority: Blocker
>             Fix For: EJB 3.0 RC10 - FD
>
>
> The classes that were bundled together to form the jboss-ejb3-all.jar of the embeddable container are not compatible.
> I am calling the following code...
> {code}
>         EJB3StandaloneBootstrap.boot(null);
>         
>         Collection<URL> deployDirs = getDeployDirURLs();
>         Collection<URL> persistenceArchives = getPersistenceArchiveURLs();
>         
>         deployer = EJB3StandaloneBootstrap.createDeployer();
>         .... get deploy dirs ..
>         deployer.getDeployDirs().addAll(deployDirs);
>         deployer.create();
>         deployer.start();
> {code}
> When the code gets to deployer.create(); it fails with the following stack trace
> {noformat}
> java.lang.NoSuchMethodError: org/jboss/ejb3/Ejb3Deployment.<init>(Lorg/jboss/ejb3/DeploymentUnit;Lorg/jboss/ejb3/EAR;)V
> 	at org.jboss.ejb3.embedded.EJB3StandaloneDeployment.<init>(EJB3StandaloneDeployment.java:49)
> 	at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.create(EJB3StandaloneDeployer.java:438)
> 	at com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:84)
> 	at com.dolby.pics.test.TestSetupWrapper.setUp(TestSetupWrapper.java:32)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:615)
> 	at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> 	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> 	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> 	at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:615)
> 	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> 	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> {noformat}
> The error as you can see is an incompatability between 
> {noformat}
> org.jboss.ejb3.embedded.EJB3StandaloneDeployment 
> {noformat}
> and 
> {noformat}
> org.jboss.ejb3.Ejb3Deployment
> {noformat}
> I'm guessing that these are from different jars and have been bundled into the same jar without a compile any tests to check that they are compatible.
> My code worked absolutely fine with alpha 8 of the embeddable container.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:54:54 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 11:54:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <28719848.1158594894950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.6.CR1)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 12:18:53 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Mon, 18 Sep 2006 12:18:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3554) Upgrade JBoss AS
 to use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15494245.1158596333118.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3554?page=comments#action_12343483 ] 
            
Stan Silvert commented on JBAS-3554:
------------------------------------

Almost.  From the dev list and the wiki, it looks like they are working out the logistics of getting the release on the downloads page and finalizing the release announcement.

http://wiki.apache.org/myfaces/CoreRelease114



> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 12:38:51 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 12:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3601) Switch copyright
 to RedHat Middleware LLC
In-Reply-To: <5022893.1157131903947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4339621.1158597531402.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3601?page=comments#action_12343484 ] 
            
Dimitris Andreadis commented on JBAS-3601:
------------------------------------------

Updated build/copyright.txt in all branches.

> Switch copyright to RedHat Middleware LLC
> -----------------------------------------
>
>                 Key: JBAS-3601
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3601
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Something like:
> /*
> * JBoss, Home of Professional Open Source
> * Copyright 2006, Red Hat Middleware LLC., and individual contributors as indicated 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 12:40:57 2006
From: jira-events at jboss.com (Britt Miner (JIRA))
Date: Mon, 18 Sep 2006 12:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-753) Leaving a Superstate
 does not record a NodeLog
Message-ID: <11880179.1158597657146.JavaMail.jira@cloud.prod.atl2.jboss.com>

Leaving a Superstate does not record a NodeLog
----------------------------------------------

                 Key: JBPM-753
                 URL: http://jira.jboss.com/jira/browse/JBPM-753
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Britt Miner
         Assigned To: Tom Baeyens


Leaving a Superstate should persist a NodeLog, but doesn'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

        


From jira-events at jboss.com  Mon Sep 18 12:42:52 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Mon, 18 Sep 2006 12:42:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28558780.1158597772797.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-132?page=comments#action_12343485 ] 
            
Daniel Brum commented on JBESB-132:
-----------------------------------

Can you please clarify this one?  What's the issue with the TB exactly?

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.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

        


From jira-events at jboss.com  Mon Sep 18 12:44:51 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Mon, 18 Sep 2006 12:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22664145.1158597891950.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-130?page=comments#action_12343486 ] 
            
Daniel Brum commented on JBESB-130:
-----------------------------------

Mark, can you verify this one?  there is a 'product' folder in the Beta1 tagged version under SVN.  There is a TRUNK folder also which I don't think should be there though.

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 13:06:55 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Mon, 18 Sep 2006 13:06:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
In-Reply-To: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15934674.1158599215239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3654?page=comments#action_12343487 ] 
            
Sakthi Samabsivam commented on JBAS-3654:
-----------------------------------------

Thanks for the quick response. As told, I am trying to create dependency between components under the EAR and not between two EARs. 
I am referring a similar case https://na1.salesforce.com/50030000001Rs96?srPos=2&srKp=500 wherein your reponse says 

"The components of an EAR do support dependency, so you can have an EJB or WAR in 
one EAR <depends> on another EJB or WAR from a different EAR." 

I am trying to follow the same in my example. This works fine till 4.0.1 SP1, but fails in 4.0.3SP1, 4.0.4 GA.

Please find the EARs attached.

> The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC1,  JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Dimitris Andreadis
>
> When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
> for example.  I have two ears example1. ear and example2.ear.
> I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
> So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml
>  <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
> This depends is working till jboss 4.0.1
> It fails in 4.0.3 SP1 , 4.0.4 GA
> 15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
> ment:war=crimeportal.war,id=-1360680885
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
> e: (javax.security.jacc.PolicyContextException: Operation not allowed)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
>         at org.jboss.web.WebModule.startModule(WebModule.java:68)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at org.jboss.system.ServiceController.start(ServiceController.java:446)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy21.start(Unknown Source)
>         at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy9.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
> tScanner.java:319)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
> canner.java:507)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
> doScan(AbstractDeploymentScanner.java:192)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
> bstractDeploymentScanner.java:265)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
>         at org.jboss.Main.boot(Main.java:187)
>         at org.jboss.Main$1.run(Main.java:438)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:201)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
> ossPolicyConfiguration.java:160)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
>         ... 94 more
> Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
> tion: linkConfiguration from state:inService
>         at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:196)
>         ... 96 more
> 15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
> ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
> 15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 13:09:01 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Mon, 18 Sep 2006 13:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
In-Reply-To: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3398355.1158599341384.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3654?page=all ]

Sakthi Samabsivam updated JBAS-3654:
------------------------------------

    Attachment: AppA.ear
                AppB.ear

Thanks for the quick response. As told, I am trying to create dependency between components under the EAR and not between two EARs. 
I am referring a similar case https://na1.salesforce.com/50030000001Rs96?srPos=2&srKp=500 wherein your reponse says

 "The components of an EAR do support dependency, so you can have an EJB or WAR in 
one EAR <depends> on another EJB or WAR from a different EAR."

 I am trying to follow the same in my example. This works fine till 4.0.1 SP1, but fails in 4.0.3SP1, 4.0.4 GA.

Please find the EARs attached.

> The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC1,  JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Dimitris Andreadis
>         Attachments: AppA.ear, AppB.ear
>
>
> When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
> for example.  I have two ears example1. ear and example2.ear.
> I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
> So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml
>  <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
> This depends is working till jboss 4.0.1
> It fails in 4.0.3 SP1 , 4.0.4 GA
> 15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
> ment:war=crimeportal.war,id=-1360680885
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
> e: (javax.security.jacc.PolicyContextException: Operation not allowed)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
>         at org.jboss.web.WebModule.startModule(WebModule.java:68)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at org.jboss.system.ServiceController.start(ServiceController.java:446)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy21.start(Unknown Source)
>         at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy9.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
> tScanner.java:319)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
> canner.java:507)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
> doScan(AbstractDeploymentScanner.java:192)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
> bstractDeploymentScanner.java:265)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
>         at org.jboss.Main.boot(Main.java:187)
>         at org.jboss.Main$1.run(Main.java:438)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:201)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
> ossPolicyConfiguration.java:160)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
>         ... 94 more
> Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
> tion: linkConfiguration from state:inService
>         at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:196)
>         ... 96 more
> 15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
> ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
> 15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 13:22:50 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 18 Sep 2006 13:22:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3150) Cipher attribute in
 the SSL Connector is ignored
Message-ID: <25971741.1158600170467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3150?page=all ]

Anil Saldhana resolved JBAS-3150.
---------------------------------

    Resolution: Rejected

I reject this as a bug for the following reason.

When the user configures a comma-separated list of ciphers, then there are two criteria that are applied to figure out the final cipher suite:

Requested Cipher Suite and the default cipher suite (provided by the JDK SSLSocketFactory)
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSocketFactory.html 

So basically, if the user configures:  ciphers = "TEST_DUMMY"
then the request cipher suite is "TEST_DUMMY" where as the default cipher suite can be:
-------------------------------------------------------------------------------------------------------------------------------
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[0]=SSL_RSA_WITH_RC4_128_MD5
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[1]=SSL_RSA_WITH_RC4_128_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[2]=TLS_RSA_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[3]=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[4]=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[5]=SSL_RSA_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[6]=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[7]=SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[8]=SSL_RSA_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[9]=SSL_DHE_RSA_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[10]=SSL_DHE_DSS_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[11]=SSL_RSA_EXPORT_WITH_RC4_40_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[12]=SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[13]=SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[14]=SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[15]=TLS_RSA_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[16]=TLS_DHE_RSA_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[17]=TLS_DHE_DSS_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[18]=SSL_RSA_WITH_NULL_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[19]=SSL_RSA_WITH_NULL_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[20]=SSL_DH_anon_WITH_RC4_128_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[21]=TLS_DH_anon_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[22]=TLS_DH_anon_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[23]=SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[24]=SSL_DH_anon_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[25]=SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[26]=SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
================================================================================================

Since the request cipher does not exist in the default cipher, the default cipher list applies.

Now, if I configure ciphers = "TEST_DUMMY,SSL_RSA_WITH_3DES_EDE_CBC_SHA"
then the logic would enable such that the final cipher will be restricted to "SSL_RSA_WITH_3DES_EDE_CBC_SHA"

=============================================================
ERROR [STDERR] Cipher:[0]=SSL_RSA_WITH_3DES_EDE_CBC_SHA
=============================================================


===============================================
protected String[] getEnabledCiphers(String arg0, String[] arg1)
   { 
      String[] baseCiphers =  super.getEnabledCiphers(arg0, arg1);
      //Print them out
      int len = baseCiphers != null ? baseCiphers.length: 0;
      
      for(int i = 0; i < len; i++)
      {
         System.err.println("Cipher:["+i+"]=" + baseCiphers[i]);
      }
      return baseCiphers;
   }
================================================


So the behavior is consistent with what is expected.  If the cipher suite
provided does not contain any of the default ciphers supported by the JDK,
then the default ciphers apply.

So in theory, you should have atleast one cipher that is supported by the JDK in your
cipher restriction.




> Cipher attribute in the SSL Connector is ignored
> ------------------------------------------------
>
>                 Key: JBAS-3150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Security
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> Please refer to the forum thread for more information.
> Please investigate this issue.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:33:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 14:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <363734.1158604381750.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=comments#action_12343493 ] 
            
Clebert Suconic commented on JBMESSAGING-432:
---------------------------------------------

Tim,

I'm just changing ClientConnectionFactoryDeleage to change that client. If you could please verify if this is correct.

I have executed testcases and this didn't change any behavior.

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:35:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
Message-ID: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace the dom4j dependency with a jarjar'ed equivalent
--------------------------------------------------------

                 Key: JBAS-3666
                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:37:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 14:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12334505.1158604621195.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3666?page=comments#action_12343494 ] 
            
Dimitris Andreadis commented on JBAS-3666:
------------------------------------------

Scott put the jarjard dom4j jar into the repository here:
http://repository.jboss.com/dom4j/1.6.1.jarjar

It contains the dom4j-jarjar.jar (which uses an org.jboss.dom4j root package namespace), and the jarjar build script.

All that is left is to update all the bootstrap modules which use dom4j(jmx/j2se/system/system-jmx) to use the new namespace. The dom4j jars could be embedded into one of these module output jars as an implementation detail to reduce the number of bootstrap jars if desired.

> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:39:09 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 14:39:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <21331661.1158604749620.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Clebert Suconic closed JBMESSAGING-432.
---------------------------------------

    Resolution: Done

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:55:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Mon, 18 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-355) Constructor
 injection of component dependencies
Message-ID: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>

Constructor injection of component dependencies
-----------------------------------------------

                 Key: JBSEAM-355
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
             Project: JBoss Seam
          Issue Type: Feature Request
            Reporter: Christian Bauer
            Priority: Minor


Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 

Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.

Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:13:02 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 15:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <19487692.1158606782844.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Clebert Suconic reopened JBMESSAGING-432:
-----------------------------------------

             

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:25:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <27837962.1158607501383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=comments#action_12343502 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-432:
---------------------------------------------

Disconnecting the client will make TIME_WAIT state TCP/IP connections accumulate again, so this is not the right fix.
Minor issue anyway, pushed for later, when we'll have time for it.

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:27:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <29300118.1158607621349.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov updated JBMESSAGING-432:
----------------------------------------

    Fix Version/s: 1.2.1
                       (was: 1.0.1.CR5)

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.2.1
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:49:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
In-Reply-To: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10172500.1158608941953.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-540?page=all ]

Ovidiu Feodorov updated JBMESSAGING-540:
----------------------------------------

    Fix Version/s: 1.2.1
                       (was: 1.0.1.CR5)

> A testsuite testing client and server on different IPs
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-540
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.1
>
>
> The current testsuite tests both client and server on the same network. 
> We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:51:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-529) Install TCK5
 locally and fix all errors that prevent Messaging from passing
In-Reply-To: <1651862.1156376026636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26388680.1158609061395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-529?page=all ]

Ovidiu Feodorov closed JBMESSAGING-529.
---------------------------------------

    Resolution: Done

Provided that the CTS is patched as promised (http://jira.jboss.org/jira/browse/JBCTS-336), all JMS tests pass 100%.

> Install TCK5 locally and fix all errors that prevent Messaging from passing
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-529
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-529
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:55:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 18 Sep 2006 15:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-9) Mavenize Security
	Build
Message-ID: <24504065.1158609301211.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mavenize Security Build
-----------------------

                 Key: SECURITY-9
                 URL: http://jira.jboss.com/jira/browse/SECURITY-9
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0


Need to convert the security build into a maven based build.

Reference:
http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation
https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:17:55 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 18 Sep 2006 16:17:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-323) Set shunning to false
 in both FD and GMS
Message-ID: <15586805.1158610675069.JavaMail.jira@cloud.prod.atl2.jboss.com>

Set shunning to false in both FD and GMS
----------------------------------------

                 Key: JGRP-323
                 URL: http://jira.jboss.com/jira/browse/JGRP-323
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Optional
             Fix For: 2.4


should be the default, even if no value is set

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:39:50 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 16:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <3092678.1158611990506.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=comments#action_12343507 ] 
            
Clebert Suconic commented on JBMESSAGING-432:
---------------------------------------------

Can we just mark won't fix?

A proper fix here would require changes on the API anyway.


> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.2.1
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:43:50 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Mon, 18 Sep 2006 16:43:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <21629670.1158612230497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3345?page=all ]

Remy Maucherat resolved JBAS-3345.
----------------------------------

    Resolution: Done

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:45:51 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 16:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <16404443.1158612351436.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov updated JBMESSAGING-432:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.1)

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:45:51 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 16:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <25618972.1158612351760.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov closed JBMESSAGING-432.
---------------------------------------

    Resolution: Won't Fix

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:51:51 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 16:51:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11060871.1158612711288.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry closed JBCACHE-769.
------------------------------------

    Resolution: Done

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 1.4.0.SP2, 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:05:53 2006
From: jira-events at jboss.com (Levi Purvis (JIRA))
Date: Mon, 18 Sep 2006 17:05:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-709)
 javaee_web_services_client_1_2.xsd is missing
Message-ID: <18921498.1158613553517.JavaMail.jira@cloud.prod.atl2.jboss.com>

javaee_web_services_client_1_2.xsd is missing
---------------------------------------------

                 Key: EJBTHREE-709
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-709
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC9 - FD, EJB 3.0 RC10 - FD
            Reporter: Levi Purvis
            Priority: Minor


When using an ejb-jar.xml file (referencing ejb-jar_3_0.xsd) with an EJB3 deployment in RC9, the following exception will be thrown.  A work-around is to download http://java.sun.com/xml/ns/javaee/javaee_web_services_client_1_2.xsd and manually add it as schema/javaee_web_services_client_1_2.xsd to server/default/lib/jboss.jar using the command-line jar tool.

2006-09-18 16:31:21,367 | DEBUG | main | EJB3Deployer | create, wps.jar
2006-09-18 16:31:21,429 | DEBUG | main | EJB3Deployer | Deploying: file:/C:/Software/Programs/jboss-4.0.4.GA/server/default/deploy/wps.jar/
2006-09-18 16:31:21,429 | DEBUG | main | ServiceController | Creating service jboss.j2ee:service=EJB3,module=wps.jar
2006-09-18 16:31:21,429 | DEBUG | main | Ejb3Module | Creating jboss.j2ee:service=EJB3,module=wps.jar
2006-09-18 16:31:21,445 | DEBUG | main | JaccHelper | Initialising JACC Context for deployment: wps.jar
2006-09-18 16:31:21,523 | DEBUG | main | EjbJarDDObjectFactory | found ejb-jar.xml file:/C:/Software/Programs/jboss-4.0.4.GA/server/default/deploy/wps.jar/META-INF/ejb-jar.xml
2006-09-18 16:31:21,695 | DEBUG | main | JBossEntityResolver | Cannot resolve [publicID=null,systemID=file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_web_services_client_1_2.xsd]
2006-09-18 16:31:21,710 | WARN | main | SaxJBossXBParser | schema_reference.4: Failed to read schema document 'javaee_web_services_client_1_2.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. @ file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_5.xsd[78,69]
2006-09-18 16:31:21,726 | DEBUG | main | Ejb3Module | Initialization failed jboss.j2ee:service=EJB3,module=wps.jar
org.jboss.xb.binding.JBossXBException: Failed to parse source: src-resolve: Cannot resolve the name 'javaee:service-refGroup' to a(n) 'group' component. @ file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_5.xsd[798,49]
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:141)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190)
	at org.jboss.ejb3.metamodel.EjbJarDDObjectFactory.parse(EjbJarDDObjectFactory.java:87)
	at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:44)
	at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:349)
	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:305)
	at org.jboss.ejb3.Ejb3Module.createService(Ejb3Module.java:77)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.create(Unknown Source)
	at org.jboss.system.ServiceController.create(ServiceController.java:330)
	at org.jboss.system.ServiceController.create(ServiceController.java:273)
	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy34.create(Unknown Source)
	at org.jboss.ejb3.EJB3Deployer.create(EJB3Deployer.java:429)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
	at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:99)
	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy35.create(Unknown Source)
	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy6.deploy(Unknown Source)
	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy4.start(Unknown Source)
	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy5.deploy(Unknown Source)
	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
	at org.jboss.Main.boot(Main.java:200)
	at org.jboss.Main$1.run(Main.java:464)
	at java.lang.Thread.run(Thread.java:595)
Caused by: org.xml.sax.SAXException: src-resolve: Cannot resolve the name 'javaee:service-refGroup' to a(n) 'group' component. @ file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_5.xsd[798,49]
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler.error(SaxJBossXBParser.java:322)
	at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
	at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDGroupTraverser.traverseLocal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSeqChoice(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSequence(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDGroupTraverser.traverseGlobal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDGroupTraverser.traverseLocal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSeqChoice(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSequence(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseGlobal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:137)
	... 120 more


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:13:51 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:13:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29122372.1158614031589.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry reopened JBCACHE-769:
--------------------------------------

             
Reopening; forget to check BdbjeCacheLoader and JdbmCacheLoader.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:15:49 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Mon, 18 Sep 2006 17:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1050) WSRP consumer
 will throw an
 NPE if the markup response from the producer is an empty string.
Message-ID: <9582939.1158614149445.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP consumer will throw an NPE if the markup response from the producer is an empty string.
--------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1050
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1050
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:23:50 2006
From: jira-events at jboss.com (john mendonca (JIRA))
Date: Mon, 18 Sep 2006 17:23:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <32393951.1158614630568.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

john mendonca updated JBAS-3641:
--------------------------------

    Attachment: jboss_init_hpux.sh

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh, jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:27:48 2006
From: jira-events at jboss.com (john mendonca (JIRA))
Date: Mon, 18 Sep 2006 17:27:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <9971196.1158614868821.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

john mendonca updated JBAS-3641:
--------------------------------


I've tested jboss_init_hpux.sh with 4.0.5.CR1 as requested.

I took the opportunity to make further changes to the script before testing:
- additional error checks (for userid, permissions, java or JAVA_HOME)
- always wait up for up to 30 seconds for JBoss to terminate gracefully

Cheers,
- John

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh, jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7819207.1158616069115.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25721216.1158616069279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25320856.1158616069400.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30919774.1158616069530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:52 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30653799.1158616192785.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=comments#action_12343512 ] 
            
Clebert Suconic commented on JBMESSAGING-525:
---------------------------------------------

I have tested this basically by deploying a postgres datasource on a JBoss 4.0 and didn't find any issues.

The SQL look ok to me also, since I have a lot of experience with SQL.


So, the patch was applied.

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Beta1, 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:52 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:49:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20112256.1158616193004.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry closed JBCACHE-769.
------------------------------------

    Resolution: Done

JDBCCacheLoader, AsyncCacheLoader, and BdbjeCacheLoader were fixed in both HEAD and Branch_1_4_0.  In HEAD the new AbstractCacheLoader was fixed as well.  Other CacheLoader impls were already OK.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 1.4.0.SP2, 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2746623.1158616193159.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic closed JBMESSAGING-525.
---------------------------------------

    Resolution: Done

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28479696.1158616193329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic reopened JBMESSAGING-525:
-----------------------------------------

             

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Beta1, 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19324597.1158616193472.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic updated JBMESSAGING-525:
----------------------------------------

    Fix Version/s: 1.2.0.Beta1

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Beta1, 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16436910.1158616193629.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic closed JBMESSAGING-525.
---------------------------------------

    Resolution: Done

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Beta1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:57:48 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:57:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-302) Invoking
 Topic management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <25996999.1158616668477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=comments#action_12343516 ] 
            
Clebert Suconic commented on JBMESSAGING-302:
---------------------------------------------

This is not a messaging Bug.
This is throw by the JMX console. As you can see there isn't any JMS code on the stack trace.

We could add an overload method without any parameters, but you can still have this exception if you don't set parameters on listMessagesNonDurableSub().


I didn't find any issues wih tlistMessagesDurableSub since all of its parameters are Strings.

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:05:49 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Mon, 18 Sep 2006 18:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1020) Replace direct
 uses of Log4J by JBoss logging.
In-Reply-To: <5738105.1157481328815.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7906061.1158617149164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1020?page=all ]

Chris Laprun reassigned JBPORTAL-1020:
--------------------------------------

    Assignee: Chris Laprun

> Replace direct uses of Log4J by JBoss logging.
> ----------------------------------------------
>
>                 Key: JBPORTAL-1020
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1020
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2 Branch
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:05:49 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Mon, 18 Sep 2006 18:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1050) WSRP consumer
 will throw an
 NPE if the markup response from the producer is an empty string.
In-Reply-To: <9582939.1158614149445.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10258698.1158617149292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1050?page=all ]

Chris Laprun resolved JBPORTAL-1050.
------------------------------------

    Resolution: Done

> WSRP consumer will throw an NPE if the markup response from the producer is an empty string.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1050
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1050
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:07:48 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 18:07:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <20582952.1158617268465.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Clebert Suconic closed JBMESSAGING-302.
---------------------------------------

    Fix Version/s:     (was: 1.0.1.CR5)
       Resolution: Won't Fix

Ovidiu,

Please reopen this issue if I am missing something..

Aas I said before, this exception is happening on the JMX console. I don't think we can do anything here.




> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:09:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 18:09:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24383008.1158617390513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1034.
-------------------------------------------

    Resolution: Done

> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 1 week, 7 hours
>
> - define architecture, goals and roadmap for portal - ldap integration
> - prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:27:49 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-22) Nullify @In
 properties after end of invocation
Message-ID: <20455998.1158618469892.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-22?page=all ]

Gavin King closed JBSEAM-22.
----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

done. it was needed to make noisy transient declaration unnecessary

> Nullify @In properties after end of invocation
> ----------------------------------------------
>
>                 Key: JBSEAM-22
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-22
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Minor
>             Fix For: 1.1
>
>
> It may be desirable to nullify any injected dependencies when the invocation ends.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:33:50 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:33:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-352) debug.seam should be
 able to display interceptors for a given component
In-Reply-To: <27074460.1158165395733.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10633010.1158618830544.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-352?page=all ]

Gavin King closed JBSEAM-352.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

OK, just 'specially for you :)

> debug.seam should be able to display interceptors for a given component
> -----------------------------------------------------------------------
>
>                 Key: JBSEAM-352
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-352
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Stephan Bublava
>         Assigned To: Gavin King
>            Priority: Trivial
>             Fix For: 1.1
>
>
> It would be great, if debug.seam would display all interceptors that are enabled for a component. This just requires two getter methods for Component.interceptors and Component.clientSideInterceptors.
> I can deliver a patch if desired...

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:35:50 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 18:35:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-526) JMSRedelivered
 flag not correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26822451.1158618950211.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Clebert Suconic updated JBMESSAGING-526:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:43:49 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-337) @Startup component
 with @Create is broken
In-Reply-To: <31262222.1156201658694.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11328172.1158619429860.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-337?page=all ]

Gavin King closed JBSEAM-337.
-----------------------------

    Resolution: Done

thanks, fixed now

> @Startup component with @Create is broken
> -----------------------------------------
>
>                 Key: JBSEAM-337
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-337
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Shane Bryzak
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>         Attachments: testcase.zip
>
>
> A component annotated with @Startup having a method annotated with @Create throws the following exception during deployment:
> 09:01:45,140 INFO  [Lifecycle] starting up: applicationContext
> 09:01:45,140 INFO  [Lifecycle] starting up: startupBean
> 09:01:45,156 ERROR [STDERR] java.lang.IllegalStateException: No active event context
> 09:01:45,156 ERROR [STDERR]     at org.jboss.seam.core.Manager.instance(Manager.java:320)
> 09:01:45,156 ERROR [STDERR]     at org.jboss.seam.interceptors.ConversationInterceptor.isMissingJoin(ConversationInterceptor.java:100)
> 09:01:45,156 ERROR [STDERR]     at org.jboss.seam.interceptors.ConversationInterceptor.endOrBeginLongRunningConversation(ConversationInterceptor.java:43)
> 09:01:45,156 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:45:49 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1039721.1158619549184.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=all ]

Gavin King closed JBSEAM-347.
-----------------------------

    Resolution: Won't Fix
      Assignee: Gavin King

According to the most recent comment, this issue appears to be "solved" on the user end.

> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>         Assigned To: Gavin King
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:47:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:47:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-136)
	@StartTask(pageFlow="...")
Message-ID: <15828302.1158619667648.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-136?page=all ]

Gavin King closed JBSEAM-136.
-----------------------------

    Resolution: Done
      Assignee: Gavin King

I understand that this problem was already fixed by a new jBPM release.

> @StartTask(pageFlow="...")
> --------------------------
>
>                 Key: JBSEAM-136
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-136
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: BPM
>            Reporter: Gavin King
>         Assigned To: Gavin King
>         Attachments: ToDo_jBPM_Example.zip
>
>
> There is no test for a pageflow attached to a task. A user reports that this is broken.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:47:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:47:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-339) Event scope
 container (WebRequestContext) doesn't clean the beans after destroy
In-Reply-To: <32055035.1156507726254.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <728205.1158619667777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-339?page=all ]

Gavin King updated JBSEAM-339:
------------------------------

    Issue Type: Feature Request  (was: Bug)
      Priority: Minor  (was: Critical)

This is not a bug and is not critical.

> Event scope container (WebRequestContext) doesn't clean the beans after destroy
> -------------------------------------------------------------------------------
>
>                 Key: JBSEAM-339
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-339
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1, 1.1
>         Environment: Jboss Seam nightly build 20060821, myfaces 1.1.4-SNAPSHOT from cvs. Tomahawk and tomahawk-snapshot 1.1.5-SNAPSHOT from cvs facelets 1.1.11
>            Reporter: German de la Cruz
>            Priority: Minor
>         Attachments: bulk.tar.gz, path_to_flush_beans.path
>
>
> Please, after the flushAndDestroyContext call, clean the destroyed bean from the event scope session (and therefore from the http request object. It produces a bug with tomahawk-sandbox and event scoped session bean. The destroyed beans are anyway invalid references and must be destroyed. 
> I've made a very simple patch, but anyway, it can't solve the problem since some modifications in tomahawk sandbox is needed. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:47:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:47:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBSEAM-339) Event scope
 container (WebRequestContext) doesn't clean the beans after destroy
In-Reply-To: <32055035.1156507726254.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28378873.1158619667946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-339?page=all ]

Gavin King reassigned JBSEAM-339:
---------------------------------

    Assignee: Gavin King

> Event scope container (WebRequestContext) doesn't clean the beans after destroy
> -------------------------------------------------------------------------------
>
>                 Key: JBSEAM-339
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-339
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1, 1.1
>         Environment: Jboss Seam nightly build 20060821, myfaces 1.1.4-SNAPSHOT from cvs. Tomahawk and tomahawk-snapshot 1.1.5-SNAPSHOT from cvs facelets 1.1.11
>            Reporter: German de la Cruz
>         Assigned To: Gavin King
>            Priority: Minor
>         Attachments: bulk.tar.gz, path_to_flush_beans.path
>
>
> Please, after the flushAndDestroyContext call, clean the destroyed bean from the event scope session (and therefore from the http request object. It produces a bug with tomahawk-sandbox and event scoped session bean. The destroyed beans are anyway invalid references and must be destroyed. 
> I've made a very simple patch, but anyway, it can't solve the problem since some modifications in tomahawk sandbox is needed. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:51:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:51:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-315) No control over the
 process definition when using components "taskInstanceListForType" &
 "pooledTaskInstanceList"
In-Reply-To: <13639447.1153515731332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <856385.1158619907914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-315?page=all ]

Gavin King closed JBSEAM-315.
-----------------------------

    Resolution: Won't Fix

Its perfectly fine to extend Seam with your own components for task lists. We don't need this in the Seam core.

> No control over the process definition when using components "taskInstanceListForType" & "pooledTaskInstanceList"
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-315
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-315
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: BPM
>    Affects Versions: 1.0.1
>            Reporter: Aravind Kumar
>
> There may be multiple Business Processes running in the same application. with CreateProcess annotation we can instantiate process instance for a particular process definition. 
> "taskInstanceListForType" & "pooledTaskInstanceList" components relies on TaskMgmtSession.java of JBPM to pull out  the taskinstances that the current user is authorized to see. But theres no control over the precess definition.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:53:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:53:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-335)
 NullPointerException if user
 quikcly decides to click a different link or button before the page renders
In-Reply-To: <7270828.1155764675359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27535611.1158620034491.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-335?page=all ]

Gavin King updated JBSEAM-335:
------------------------------

    Priority: Critical  (was: Major)

I have also observed this.

> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-335
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-335
>             Project: JBoss Seam
>          Issue Type: Bug
>         Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
>            Reporter: Keith Naas
>            Priority: Critical
>
> When a user is on one of our screens, they can decide to click a link before the next page loads.  Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181.  Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().  
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.  
> Stack Trace
> java.lang.NullPointerException
> 	at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> 	at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> 	at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> 	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> .....

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:53:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:53:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-319) s:link does not work
 after JBoss restart
In-Reply-To: <14926597.1153938371557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32998735.1158620034719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-319?page=all ]

Gavin King closed JBSEAM-319.
-----------------------------

    Resolution: Duplicate Issue

> s:link does not work after JBoss restart
> ----------------------------------------
>
>                 Key: JBSEAM-319
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-319
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1
>         Environment: jboss jems 4.0.4
> seam 1.1
>            Reporter: Chris Hane
>
> On a results screen I use the s:link tag in a table. The results screen is generated from a SFSB with ScopeType.EVENT. When the user clicks on the <s:link /> action, a new screen opens up from another SFSB with ScopeType.CONVERSATION.
> This works great until JBoss is restarted. Once restarted, the view action (below) on an existing results screen returns the results.xhtml screen without any records and does not seem to call the SFSB editor.view that I expected.
> See the thread for the full description.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:57:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:57:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-333) UI Labels and
 displaying the hash sign #
In-Reply-To: <13781486.1155680782986.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23478308.1158620274866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-333?page=all ]

Gavin King closed JBSEAM-333.
-----------------------------

    Resolution: Duplicate Issue

> UI Labels and displaying the hash sign #
> ----------------------------------------
>
>                 Key: JBSEAM-333
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-333
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, Tomcat 5.5.15, Embeddable EJB 3 (not sure which version exactly, but built on 6/2/2006), MyFaces 1.1.2
>            Reporter: zzzz8
>
> I can't seem to display the hash character
> In my JSP page, I have the following:
> <h:outputText escape="true" value="#{messages['TestNumber']}" />	
> In my messages.properties file, I have:
> TestNumber=Test #	
> Seam cannot evaluate the EL...
> Cannot get value for expression '#{messages['RequestNumber.Short']}'	
> I've also tried the Unicode character for the hash sign:
> TestNumber=Test \u0023	
> According to user raja05, the bug is due to code in Interpolator.interpolate which looks for a token after the hash sign - which in my case, is nonexistent since the hash sign is the last character in my label:
>       FacesContext context = FacesContext.getCurrentInstance();
>       StringTokenizer tokens = new StringTokenizer(string, "#{}", true);
>       StringBuilder builder = new StringBuilder(string.length());
>       while ( tokens.hasMoreTokens() )
>       {
>          String tok = tokens.nextToken();
>          if ( "#".equals(tok) )
>          {
>             String nextTok = tokens.nextToken();

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:59:53 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:59:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-100) Unify datasource
 configuration factory with E-EJB3
Message-ID: <14193285.1158620394011.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-100?page=all ]

Gavin King updated JBSEAM-100:
------------------------------

    Issue Type: Feature Request  (was: Bug)

> Unify datasource configuration factory with E-EJB3
> --------------------------------------------------
>
>                 Key: JBSEAM-100
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-100
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Trivial
>         Attachments: JBSEAM-100.zip
>
>
> The org.jboss.resource.adapter.jdbc.local.LocalTxDataSource does the same as org.jboss.seam.microcontainer.DataSourceFactory - they are slightly different in configuration only. 
> For example:
> - connectionUrl vs. connectionURL
> - getDatasource vs. getDataSource
> - etc.
> One internal difference is the CachedConnectionManager. It is injected into the LocalTxDataSource, but instantiated in the seam.microcontainer.DataSourceFactory.
> I think we should either unify, or better, kick out one of those two.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:01:53 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:01:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-348) IssueTracker example
 uses nonexisting annotation (Within)
In-Reply-To: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32988049.1158620513922.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-348?page=all ]

Gavin King closed JBSEAM-348.
-----------------------------

    Resolution: Done

Was already fixed

> IssueTracker example uses nonexisting annotation (Within)
> ---------------------------------------------------------
>
>                 Key: JBSEAM-348
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>         Attachments: jbseam-348-patch.txt
>
>
> org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Mon Sep 18 19:05:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:05:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-312) seam dvd example -
 confirm.xhtml, 
 order.totalAmount have to be currentOrder.totalAmount
In-Reply-To: <23141316.1153224733923.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19704006.1158620754836.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-312?page=all ]

Gavin King closed JBSEAM-312.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done

thanks, fixed

> seam dvd example - confirm.xhtml, order.totalAmount have to be currentOrder.totalAmount
> ---------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-312
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-312
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4 AS - Sun JDK 1.5.07
>            Reporter: Torsten Krah
>            Priority: Trivial
>             Fix For: 1.1
>
>   Original Estimate: 1 minute
>  Remaining Estimate: 1 minute
>
> In confirm.xhtml the el expression for totalamount needs to be currentOrder.totalAmount, not order.totalAmount.
> kind regards
> Torsten

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:19:52 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:19:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-309) Debug page throws
 LIE when viewing entity bean with lazy collection
In-Reply-To: <28104447.1152862331460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11151576.1158621592862.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-309?page=all ]

Gavin King closed JBSEAM-309.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

fixed

> Debug page throws LIE when viewing entity bean with lazy collection
> -------------------------------------------------------------------
>
>                 Key: JBSEAM-309
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-309
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Christian Bauer
>         Assigned To: Gavin King
>            Priority: Minor
>             Fix For: 1.1
>
>
> When I click on my logged in user variable in the Session context on the Seam debug page I get a LIE for a lazy collection in that user entity bean instance.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:21:55 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:21:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-279) Component lifetimes
 not guaranteed for SFSB backed components.
Message-ID: <15544864.1158621715280.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-279?page=all ]

Gavin King closed JBSEAM-279.
-----------------------------

    Resolution: Won't Fix

This is not a bug in Seam, it is merely an inconvenient set of defaults in EJB3 and Tomcat in JBoss AS. Please take this discussion elsewhere, since this issue report is not useful here.

> Component lifetimes not guaranteed for SFSB backed components.
> --------------------------------------------------------------
>
>                 Key: JBSEAM-279
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-279
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: ryan dewell
>
> Seam does not guarantee component lifecycles for SFSB backed components.  
> The container controls when SFSB's are removed / timed out.  When Seam accesses an SFSB that has been removed by the container, it results in an EJBNoSuchObjectException.
> The JBoss specific workaround for Session scoped components is to use the @CacheConfig annotation, setting the idle timeout to match the HttpSession timeout.  Similar changes would have to be made to any Conversation scoped component that uses a timeout greater than the default SFSB timeout of 5 minutes (which just happens to be the default timeout for Seam conversations).
> There is no workaround for Application scoped components.  Once removed by the container, EJBNoSuchObjectException's will continue to be thrown as Seam tries to access them.
> Seam's context model needs to somehow guarantee that its SFSB instances aren't removed by the container before Seam is finished with them.  And/or, it needs to recover from EJBNoSuchObjectException's more gracefully, especially with regards to Application scoped components for which there is no workaround.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:25:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:25:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-323) NPE when calling
 WebRemote method returning interface
In-Reply-To: <20944284.1153988831592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17518683.1158621954662.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-323?page=all ]

Gavin King closed JBSEAM-323.
-----------------------------

    Resolution: Done

Closing this, because the immediate bug is fixed, and there is another issue for the second problem.

> NPE  when calling  WebRemote method returning interface
> -------------------------------------------------------
>
>                 Key: JBSEAM-323
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-323
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 1.1
>            Reporter: Michael Steiner
>         Assigned To: Shane Bryzak
>            Priority: Minor
>
> InterfaceGenerator calls  c = c.getSuperclass(); for interaces it is null than calls  !c.equals(Object.class) and this throws NullPointerException.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:25:55 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:25:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-270) Annotations
 @DataModelSelection
 and @DataModelSelectionIndex can't be used in one component together
Message-ID: <20662398.1158621955640.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-270?page=all ]

Gavin King updated JBSEAM-270:
------------------------------

    Issue Type: Feature Request  (was: Bug)
      Priority: Minor  (was: Major)

> Annotations @DataModelSelection and @DataModelSelectionIndex can't be used in one component together
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-270
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-270
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 1.0
>         Environment: WinXP Professional
> JBoss AS 4.0.4.GA (ejb3.deployer libs replaced by EJB3 RC8 libs)
> myFaces Core 1.1.3
> Tomahawk 1.1.3
> Facelets (as in Seam 1.0.0.GA)
> JDK1.5.0_06
>            Reporter: Jens Weintraut
>            Priority: Minor
>
> A seam component can't use both annotations @DataModelSelection and @DataModelSelectionIndex at once. If both are used deployment shows this error message:
> java.lang.IllegalStateException: Multiple @DataModelSelection fields for: messageList
> 	at org.jboss.seam.Component.initMembers(Component.java:533)
> 	at org.jboss.seam.Component.<init>(Component.java:199)
> 	at org.jboss.seam.Component.<init>(Component.java:159)
> 	at org.jboss.seam.Component.<init>(Component.java:154)
> 	at org.jboss.seam.Component.<init>(Component.java:149)
> 	at org.jboss.seam.init.Initialization.addComponent(Initialization.java:381)
> 	at org.jboss.seam.init.Initialization.addComponents(Initialization.java:343)
> 	at org.jboss.seam.init.Initialization.init(Initialization.java:195)
> 	at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:32)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729)
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:29:56 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-313) <s:validateAll> +
 facelets user tag
In-Reply-To: <22846419.1153495271497.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216850.1158622196717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-313?page=all ]

Gavin King closed JBSEAM-313.
-----------------------------

    Resolution: Won't Fix

AFAIK, there is nothing I can do in Seam to fix this. It is a limit of facelets.

> <s:validateAll> + facelets user tag
> -----------------------------------
>
>                 Key: JBSEAM-313
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-313
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: jBoss 4.0.4.GA
> Seam 1.0.1.GA
>            Reporter: Denis Karpov
>         Attachments: test.zip
>
>
> =================================================
> *.xhtml file:
> --------------------
> .....
> <s:validateAll>
> 	<clv:edit id="edit" label="Test editable" value="#{test.obj.code}"/>  <!-- User defined tag inside validateAll-->
> </s:validateAll>
> .....
> ==================================================
> tag file:
> -----------------
> ....
> <ui:component 	xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">
> 	<input id="#{id}" type="text" jsfc="h:inputText" value="#{value}"/>   <!--  Look at #{value} This is the root of problem -->
> </ui:component>
> ....
> =================================================
> Look at  value=#{value}
> Validation framework now can not process such binding that concerns facelets templateing.
> In attachment you will find simple working project. Just uncomment <!--s:validateAll--> and you will get exception.
> Exception:
> 19:07:19,921 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
> java.lang.RuntimeException: not an attribute value binding: #{value}
> 	at org.jboss.seam.ui.ModelValidator.validate(ModelValidator.java:30)
> 	at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157)
> 	at javax.faces.component.UIInput.validateValue(UIInput.java:312)
> 	at javax.faces.component.UIInput.validate(UIInput.java:353)
> 	at javax.faces.component.UIInput.processValidators(UIInput.java:183)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIForm.processValidators(UIForm.java:70)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:146)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:262)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:35:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:35:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-343) Action method of
 source page being executed after destination action
In-Reply-To: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31390721.1158622554488.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-343?page=comments#action_12343544 ] 
            
Gavin King commented on JBSEAM-343:
-----------------------------------

Not so fast:

(1) The fix is no good, since if the page we are supposed to be rendering had a page action, it would not get called.
(2) Pages.callAction(FacesContext) actually updates the view-id, so your explanation for the cause of the behavior does not seem to be correct

> Action method of source page being executed after destination action
> --------------------------------------------------------------------
>
>                 Key: JBSEAM-343
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, jboss installation per Seam setup instructions
>            Reporter: Todd Main
>
> I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:
> Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".
>    <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>
> There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.
>                             <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
>                                 <f:param name="dayRange" value="7" />
>                                 <f:param name="documentCategory" value="po" />
>                                 #{quickClicksData.ordersFromLastSeven}
>                             </s:link>
> When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.
> Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:
> This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is
> Code:
>    
>    public boolean callPageActions(PhaseEvent event)
>    {
>       Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
>       boolean actionsWereCalled = false;
>       try
>       {
>          actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>          actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
>          return actionsWereCalled;
> The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.
> If the code were
> Code:
>     actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>     actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
>     return actionsWereCalled;
> 	
> that should fix this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:37:52 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:37:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-343) Action method of
 source page being executed after destination action
In-Reply-To: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13380722.1158622672400.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-343?page=comments#action_12343545 ] 
            
Gavin King commented on JBSEAM-343:
-----------------------------------

Are you sure you have tested this against current CVS? If you have, I need a copy of your very simple test case.

> Action method of source page being executed after destination action
> --------------------------------------------------------------------
>
>                 Key: JBSEAM-343
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, jboss installation per Seam setup instructions
>            Reporter: Todd Main
>
> I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:
> Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".
>    <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>
> There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.
>                             <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
>                                 <f:param name="dayRange" value="7" />
>                                 <f:param name="documentCategory" value="po" />
>                                 #{quickClicksData.ordersFromLastSeven}
>                             </s:link>
> When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.
> Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:
> This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is
> Code:
>    
>    public boolean callPageActions(PhaseEvent event)
>    {
>       Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
>       boolean actionsWereCalled = false;
>       try
>       {
>          actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>          actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
>          return actionsWereCalled;
> The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.
> If the code were
> Code:
>     actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>     actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
>     return actionsWereCalled;
> 	
> that should fix this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:41:58 2006
From: jira-events at jboss.com (Todd Main (JIRA))
Date: Mon, 18 Sep 2006 19:41:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-343) Action method of
 source page being executed after destination action
In-Reply-To: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14272299.1158622918468.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-343?page=comments#action_12343546 ] 
            
Todd Main commented on JBSEAM-343:
----------------------------------

I did test it against CVS at the time, as I was still using the CVS version then.  I don't have a simple test case right now, but I'll try to create one soon.

> Action method of source page being executed after destination action
> --------------------------------------------------------------------
>
>                 Key: JBSEAM-343
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, jboss installation per Seam setup instructions
>            Reporter: Todd Main
>
> I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:
> Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".
>    <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>
> There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.
>                             <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
>                                 <f:param name="dayRange" value="7" />
>                                 <f:param name="documentCategory" value="po" />
>                                 #{quickClicksData.ordersFromLastSeven}
>                             </s:link>
> When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.
> Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:
> This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is
> Code:
>    
>    public boolean callPageActions(PhaseEvent event)
>    {
>       Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
>       boolean actionsWereCalled = false;
>       try
>       {
>          actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>          actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
>          return actionsWereCalled;
> The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.
> If the code were
> Code:
>     actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>     actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
>     return actionsWereCalled;
> 	
> that should fix this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:43:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 19:43:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-302) Invoking
 Topic management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <24951276.1158623034398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-302:
-----------------------------------------

      Assignee: Ovidiu Feodorov  (was: Clebert Suconic)
             

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:47:53 2006
From: jira-events at jboss.com (ryan dewell (JIRA))
Date: Mon, 18 Sep 2006 19:47:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-279) Component
 lifetimes not guaranteed for SFSB backed components.
Message-ID: <14053820.1158623273290.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-279?page=comments#action_12343547 ] 
            
ryan dewell commented on JBSEAM-279:
------------------------------------

Two different containers, interdependent, Seam and JBoss, each with their own idea about how long components should exist.  The fix lies in the configuration of one of those containers.  Changing the Jboss cache configuration is one of those solutions, the only solution so far presented in fact.

At the very least, if Seam as a component container truly considers this an "inconvenient set of defaults", then let's see the "convenient set of defaults" added to the Seam documentation.

> Component lifetimes not guaranteed for SFSB backed components.
> --------------------------------------------------------------
>
>                 Key: JBSEAM-279
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-279
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: ryan dewell
>
> Seam does not guarantee component lifecycles for SFSB backed components.  
> The container controls when SFSB's are removed / timed out.  When Seam accesses an SFSB that has been removed by the container, it results in an EJBNoSuchObjectException.
> The JBoss specific workaround for Session scoped components is to use the @CacheConfig annotation, setting the idle timeout to match the HttpSession timeout.  Similar changes would have to be made to any Conversation scoped component that uses a timeout greater than the default SFSB timeout of 5 minutes (which just happens to be the default timeout for Seam conversations).
> There is no workaround for Application scoped components.  Once removed by the container, EJBNoSuchObjectException's will continue to be thrown as Seam tries to access them.
> Seam's context model needs to somehow guarantee that its SFSB instances aren't removed by the container before Seam is finished with them.  And/or, it needs to recover from EJBNoSuchObjectException's more gracefully, especially with regards to Application scoped components for which there is no workaround.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:17:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:17:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-520) Messages
 received from
 Receiver.receive() using an XA are never deleted from the database if not
 withing a transactional boundary.
In-Reply-To: <23416910.1155654737451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2460768.1158639474635.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]

Ovidiu Feodorov closed JBMESSAGING-520.
---------------------------------------

    Resolution: Done

Modified an XASession to behave as a non-transactional session, unless associated with a global transaction. See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968696 for more details.

> Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-520
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>         Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
>            Reporter: Joel Lindheimer
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> Create a simple receiver, but do not place it within a Transaction boundary; shut down the server; look up the tables and you will see all the messages are still in the Messages and MessageRef tables.
> =========================================
> Observations using a debbuger reveal the following:
> =========================================
> Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method will always call createXAQueueSession() and create an XAQueconnection as transacted and Session.SESSION_TRANSACTED.  That being the case, non-XA Queues have no message-deletion problems with the current version (RC4) because the API removes all messages that are "not transacted and (!ack==1). I am guessing that using XA is problematic because the persistence layer is expecting manipulation of the transacted XASession--which for some reason is not working in this version of Messaging. More specifically, I suspect that when MDBs are tested you are not seeing this problem because the container is doing needed magic to manage the XASession transacted state, and therefore everything works fine therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver, there is something missing in the equation ergo the problems that I have been reporting regarding the ClickCommerce applications which use Receivers and not MDBs.  
> Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while waiting for a fix.

-- 
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

       



From jira-events at jboss.com  Tue Sep 19 00:17:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:17:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-410) java:/JmsXA in
 no-tx context does not work the same way as JBossMQ
Message-ID: <18565884.1158639474832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ]

Ovidiu Feodorov closed JBMESSAGING-410.
---------------------------------------

    Resolution: Done

Modified an XASession to behave as a non-transactional session, unless associated with a global transaction.

> java:/JmsXA in no-tx context does not work the same way as JBossMQ
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-410
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR2
>            Reporter: Elias Ross
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory.
> Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility.
> The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced.
>       QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA");
> ...
>       QueueConnection queueConnection = queueCF.createQueueConnection();
>       QueueSession queueSession =
>           queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
>       QueueSender queueSender = queueSession.createSender(queue);
>       ObjectMessage om = queueSession.createObjectMessage();
>       queueSender.send(om);
>       queueSender.close();
>       queueSession.close();
>       queueConnection.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

        


From jira-events at jboss.com  Tue Sep 19 00:25:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:25:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20421526.1158639955286.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Ovidiu Feodorov updated JBMESSAGING-541:
----------------------------------------

    Assignee: Ron Sigal  (was: Tom  Elrod)

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 19 00:25:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:25:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-277) Setting
 remoting lease period to -1 breaks ASF
Message-ID: <14471438.1158639955415.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-277?page=all ]

Ovidiu Feodorov closed JBMESSAGING-277.
---------------------------------------

    Resolution: Done
      Assignee: Ovidiu Feodorov  (was: Ron Sigal)

All TCK tests pass, so this is not an issue anymore.

> Setting remoting lease period to -1 breaks ASF
> ----------------------------------------------
>
>                 Key: JBMESSAGING-277
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-277
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> LeasePeriod == -1 is supposed to disable remoting leasing.
> However, setting LeasePeriod to -1 breaks ASF. TCK tests don't pass anymore.
> Whoever fixes this problem, should add a functional test so the Messaging testsuite catches this problem before TCK does.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:31:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:31:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13756078.1158640314198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov updated JBMESSAGING-542:
----------------------------------------

    Priority: Critical  (was: Major)

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:35:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:35:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-521)
 IllegalStateException:
 Cannot find delivery to cancel for 1000 Message test.
In-Reply-To: <6081093.1155659662294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31184149.1158640555327.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-521?page=all ]

Ovidiu Feodorov closed JBMESSAGING-521.
---------------------------------------

    Resolution: Cannot Reproduce Bug

Closing as CR5 contains XAResource/global transaction handling changes, and I haven't been able to reproduce the race condition with the new code. If shows up again, please reopen and attach the relevant TRACE log.

> IllegalStateException: Cannot find delivery to cancel for 1000 Message test.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-521
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-521
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>         Environment: Windows XP, JBossServer4.0.4GA, Oracle10G 
>            Reporter: Joel Lindheimer
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>         Attachments: jboss.log.1, jboss.log.zip
>
>
> Receiver using XA within  a UserTransaction fails midway into 1000 message test.
> I am using the same receiver setup as in my previously logged bugs (aka all connections are
> newly retrieved within the boundary of the UserTransaction). 
> This same test succeeds:
> 1) Using a non-XA Receiver with no user transaction. 
> 2) Using an XA transaction but not within a UserTransaction boundary (however all Messages are not deleted from the messages table
> see: http://jira.jboss.com/jira/browse/JBMESSAGING-520).
> 08:48:22,968 ERROR [ExceptionUtil] SessionEndpoint[-2147483617] cancelDeliveries [5c4o722t-mzyxw2-eqwg7wan-1-eqwga5a0-1u]
> javax.jms.IllegalStateException: Cannot find delivery to cancel:-2147482831
>         at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.cancelDelivery(ServerConsumerEndpoint.java:566
> )
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.cancelDeliveries(ServerSessionEndpoint.java:476
> )
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionA
> dvised$cancelDeliveries$aop(SessionAdvised.java:131)
>         at sun.reflect.GeneratedMethodAccessor560.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate.cancelDeliveries(ClientSessionDelegate.java)
>         at org.jboss.jms.client.remoting.MessageCallbackHandler.close(MessageCallbackHandler.java:339)
>         at org.jboss.jms.client.container.ConsumerAspect.handleClosing(ConsumerAspect.java:116)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect25.invoke(ConsumerAspect25.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate.closing(ClientConsumerDelegate.java)
>         at org.jboss.jms.client.JBossMessageConsumer.close(JBossMessageConsumer.java:96)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.closeConsumer(JmsMessageConsumer.java:145)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.close(JmsMessageConsumer.java:76)
>         at org.springframework.jms.support.JmsUtils.closeMessageConsumer(JmsUtils.java:117)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.doReceiveAndExecute(DefaultMessage
> ListenerContainer.java:525)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:439)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:29,921 ERROR [RoundRobinPointToPointRouter] The receiver ConsumerEndpoint[-2147482548] is broken
> java.lang.ArithmeticException: / by zero
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.shiftTarget(RoundRobinPointToPointRoute
> r.java:218)
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.jav
> a:120)
>         at org.jboss.messaging.core.ChannelSupport.push(ChannelSupport.java:1676)
>         at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:693)
>         at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.run(ChannelSupport.java:1518)
>         at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:33,328 ERROR [ExceptionUtil] SessionEndpoint[-2147483613] cancelDeliveries [5c4o722t-mzyxw2-eqwg7wan-1-e
> qwgad9s-1x]
> javax.jms.IllegalStateException: Cannot find delivery to cancel:-2147482386
>         at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.cancelDelivery(ServerConsumerEndpoint.java:566
> )
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.cancelDeliveries(ServerSessionEndpoint.java:476
> )
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionA
> dvised$cancelDeliveries$aop(SessionAdvised.java:131)
>         at sun.reflect.GeneratedMethodAccessor560.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate.cancelDeliveries(ClientSessionDelegate.java)
>         at org.jboss.jms.client.remoting.MessageCallbackHandler.close(MessageCallbackHandler.java:339)
>         at org.jboss.jms.client.container.ConsumerAspect.handleClosing(ConsumerAspect.java:116)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect25.invoke(ConsumerAspect25.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate.closing(ClientConsumerDelegate.java)
>         at org.jboss.jms.client.JBossMessageConsumer.close(JBossMessageConsumer.java:96)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.closeConsumer(JmsMessageConsumer.java:145)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.close(JmsMessageConsumer.java:76)
>         at org.springframework.jms.support.JmsUtils.closeMessageConsumer(JmsUtils.java:117)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.doReceiveAndExecute(DefaultMessage
> ListenerContainer.java:525)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:439)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:34,125 ERROR [RoundRobinPointToPointRouter] The receiver ConsumerEndpoint[-2147482347] is broken
> java.lang.ArithmeticException: / by zero
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.shiftTarget(RoundRobinPointToPointRoute
> r.java:218)
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.jav
> a:120)
>         at org.jboss.messaging.core.ChannelSupport.push(ChannelSupport.java:1676)
>         at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:693)
>         at org.jboss.messaging.core.ChannelSupport$DeliveryRunnable.run(ChannelSupport.java:1722)
>         at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,843 ERROR [ServerConnectionEndpoint] Exception occured
> javax.jms.IllegalStateException: Failed to acknowledge delivery null
>         at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.acknowledgeTransactionally(ServerConsumerEndpo
> int.java:485)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.
> java:768)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:380)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,859 ERROR [ServerConnectionEndpoint] Failed to rollback tx
> org.jboss.jms.util.MessagingTransactionRolledBackException: Transaction was rolled back.
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:391)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,875 ERROR [ExceptionUtil] ConnectionEndpoint[-2147483634] sendTransaction [5c4o722t-mzyxw2-eqwg7wan-1
> -eqwgam6j-21]
> org.jboss.jms.util.MessagingJMSException: Failed to rollback transaction after failure in prepare
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:396)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,875 ERROR [ExceptionInterceptor] Linked exception is:
> org.jboss.jms.util.MessagingTransactionRolledBackException: Transaction was rolled back.
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:391)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,875 WARN  [TransactionImpl] XAException: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=jlindheime
> r/5614, BranchQual=, localId=5614] errorCode=XAER_RMERR
> org.jboss.jms.util.MessagingXAException: A Throwable was caught in sending the transaction
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:500)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.jms.util.MessagingJMSException: Failed to rollback transaction after failure in prepare
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:396)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         ... 16 more

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:37:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-287)
 RemotingTest.testConnectionListener() invalid
Message-ID: <16494440.1158640676646.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-287:
-------------------------------------------

    Assignee: Ovidiu Feodorov  (was: Ron Sigal)

> RemotingTest.testConnectionListener() invalid
> ---------------------------------------------
>
>                 Key: JBMESSAGING-287
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. 
> After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 01:59:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 01:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
Message-ID: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.test.messaging.jms.DurableSubscriberTest times out
------------------------------------------------------------

                 Key: JBMESSAGING-546
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.0.1.CR5




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 02:49:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 02:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-753) Leaving a
 Superstate does not record a NodeLog
In-Reply-To: <11880179.1158597657146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4189470.1158648541377.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-753?page=comments#action_12343553 ] 
            
Tom Baeyens commented on JBPM-753:
----------------------------------

holy moly... now i know why you didn't find this.  the issue i remembered was a different one.  

this one will be too hard to fix in 3.x, i think.  Probably 4.0 will have a better model for transforming logs from runtime data into usable data.

it should be possible to distill that from the current logs in one way or another, i think.  maybe it requires a few subsequent queries...

> Leaving a Superstate does not record a NodeLog
> ----------------------------------------------
>
>                 Key: JBPM-753
>                 URL: http://jira.jboss.com/jira/browse/JBPM-753
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM 3.1.2
>            Reporter: Britt Miner
>         Assigned To: Tom Baeyens
>
> Leaving a Superstate should persist a NodeLog, but doesn'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

        


From jira-events at jboss.com  Tue Sep 19 03:09:59 2006
From: jira-events at jboss.com (Sohui Gu (JIRA))
Date: Tue, 19 Sep 2006 03:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23610758.1158649799168.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=comments#action_12343554 ] 
            
Sohui Gu commented on JBSEAM-347:
---------------------------------

Thanks.I know how to solve this problem.sun reference implementation and myfaces cann't contain in lib at the same time.

> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>         Assigned To: Gavin King
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:04:59 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 04:04:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1187880.1158653099286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=comments#action_12343556 ] 
            
Ben Wang commented on JBCACHE-741:
----------------------------------

To run the GUI, do "run.bat" should kick start it. However, there is typo in
CLASSPATH=$CLASSPATH:./classes
It should be:
CLASSPATH=$CLASSPATH:./output/classes
instead.

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: jdom_example.tar
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:12:58 2006
From: jira-events at jboss.com (gunter zeilinger (JIRA))
Date: Tue, 19 Sep 2006 04:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2631)
 AttributePersistenceService should be started early
Message-ID: <24656519.1158653578660.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2631?page=comments#action_12343557 ] 
            
gunter zeilinger commented on JBAS-2631:
----------------------------------------

conf/jboss-service.xml provided by jems-installer-1.2.0.BETA2.jar does not include the AttributePersistenceService - and it is also not started by any other deploy/xxx-service.xml.

> AttributePersistenceService should be started early
> ---------------------------------------------------
>
>                 Key: JBAS-2631
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2631
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Dimitris Andreadis
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-4.0.4.CR2
>
>
> When using the installer to create a full configuration the AttributePersistenceService is started through
> ./deploy/attrpm-service.xml.
> Now since this service needs to be present before any XMBean using it, it needs to be started earlier, probably throught conf/jboss-service.xml, as we do in the .zip distribution of jboss.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:17:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-68) Tidy-up JDBC classes
Message-ID: <7981584.1158653820355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mark Little reopened JBESB-68:
------------------------------

             

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:16:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:16:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-129) Wrong jar referred
 to in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10676237.1158653819756.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Mark Little reopened JBESB-129:
-------------------------------

             

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:16:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:16:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-129) Wrong jar referred
 to in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20534035.1158653819945.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Mark Little updated JBESB-129:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:17:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-129) Wrong jar referred to
 in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6561230.1158653820151.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Mark Little closed JBESB-129.
-----------------------------

    Resolution: Done

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:18:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-68) Tidy-up JDBC classes
Message-ID: <12073635.1158653939709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mark Little updated JBESB-68:
-----------------------------

        Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                           (was: 4.0 Beta 1)
    Affects Version/s: 4.0 Beta 1
                           (was: 4.0 Alpha 1)

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:18:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-68) Tidy-up JDBC classes
Message-ID: <5034139.1158653939889.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mark Little closed JBESB-68.
----------------------------

    Resolution: Done

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11124145.1158653940028.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Mark Little reopened JBESB-128:
-------------------------------

             

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19450735.1158653940297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Mark Little updated JBESB-128:
------------------------------

        Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                           (was: 4.0)
    Affects Version/s: 4.0 Beta 1
                           (was: 4.0)

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30607186.1158653940164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment:     (was: jdom_example.tar)

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16880300.1158653940422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Mark Little closed JBESB-128.
-----------------------------

    Resolution: Done

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8539477.1158653940890.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little reopened JBESB-137:
-------------------------------

             

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20601252.1158653941062.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little updated JBESB-137:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17632296.1158653941289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little closed JBESB-137.
-----------------------------

    Resolution: Done

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11719840.1158654061495.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little reopened JBESB-112:
-------------------------------

             

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24323480.1158654061693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little updated JBESB-112:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23964205.1158654062033.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little closed JBESB-112.
-----------------------------

    Resolution: Done

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7608995.1158654062421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-132?page=all ]

Mark Little updated JBESB-132:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14983725.1158654062855.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-130?page=all ]

Mark Little updated JBESB-130:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:23:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-139) Add in ftp support
Message-ID: <25718589.1158654181382.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add in ftp support
------------------

                 Key: JBESB-139
                 URL: http://jira.jboss.com/jira/browse/JBESB-139
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation, ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Esteban Schifman
             Fix For: 4.0 Beta 1 Maintenance Pack 1




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:23:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 04:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21328235.1158654181524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment: jdom_example.tar

Latest update to fix the run.sh and run.bat.

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: jdom_example.tar
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:42:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:42:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10196429.1158655379568.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-132?page=comments#action_12343561 ] 
            
Mark Little commented on JBESB-132:
-----------------------------------

Can the trailblazer be built from an installed (binary only) distribution of JBossESB?

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:46:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:46:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18263958.1158655618097.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-130?page=comments#action_12343562 ] 
            
Mark Little commented on JBESB-130:
-----------------------------------

The trunk definitely shouldn't be there. But the product folder is at the root of our svn and not part of the actual shipped source. The trailblazer needs to be able to be built from the shipped source (you can see what that looks like from http://labs.jboss.com/file-access/default/members/jbossesb/downloads/4.0Beta1/src/jbossesb-4.0Beta1-src.zip) and the shipped binary (http://labs.jboss.com/file-access/default/members/jbossesb/downloads/4.0Beta1/binary/jbossesb-4.0Beta1.zip).

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:12:01 2006
From: jira-events at jboss.com (srk (JIRA))
Date: Tue, 19 Sep 2006 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3667) HotSpot Crashes
Message-ID: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>

HotSpot Crashes
---------------

                 Key: JBAS-3667
                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Build System
    Affects Versions: JBossAS-4.0.4.GA
         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
            Reporter: srk
         Assigned To: Ruel Loehr
            Priority: Blocker
         Attachments: hs_err_pid7517.log

When I start JBoss it crashes with the following hs-errpid*.log file generated..
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x3b514a]
#

---------------  T H R E A D  ---------------

Current thread (0x9d418f38):  VMThread [id=7520]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400

Registers:
EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206

Top of Stack: (sp=0x9d3ff230)
0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 

Instructions: (pc=0xb6ed014a)
0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 

Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x3b514a]
V  [libjvm.so+0x3dde6e]
V  [libjvm.so+0x3b5332]
V  [libjvm.so+0x422efe]
V  [libjvm.so+0x42220e]
V  [libjvm.so+0x421e97]
V  [libjvm.so+0x4bb2af]
V  [libjvm.so+0x4baca6]
V  [libjvm.so+0x4ba317]
V  [libjvm.so+0x4ba525]
V  [libjvm.so+0x4ba130]
V  [libjvm.so+0x3eca78]
C  [libpthread.so.0+0x4dac]

VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
  0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
  0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
  0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
  0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
  0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
  0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
  0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
  0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
  0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
  0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
  0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
  0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
  0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
  0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
  0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
  0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
  0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
  0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
  0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
  0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
  0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
  0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
  0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
  0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
  0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]

Other Threads:
=>0x9d418f38 VMThread [id=7520]
  0x9d42add8 WatcherThread [id=7528]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
[0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0

Heap
 PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
  eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
  from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
  to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
 PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
  object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
 PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
  object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)

Dynamic libraries:
08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java


VM Arguments:
jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
java_command: org.jboss.Main

Environment Variables:
JAVA_HOME=/usr/java/jdk1.5.0_03/
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
SHELL=/bin/bash


---------------  S Y S T E M  ---------------

OS:Red Hat Enterprise Linux ES release 3 (Taroon)

uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
libc:glibc 2.3.2 NPTL 0.60 
rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
load average:1.08 0.25 0.08

CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)

vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)



-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:12:01 2006
From: jira-events at jboss.com (srk (JIRA))
Date: Tue, 19 Sep 2006 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3667) HotSpot Crashes
In-Reply-To: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19390483.1158657121880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

srk updated JBAS-3667:
----------------------

    Attachment: hs_err_pid7517.log

Here is the log file attached.

> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>         Assigned To: Ruel Loehr
>            Priority: Blocker
>         Attachments: hs_err_pid7517.log
>
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:12:04 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 05:12:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3399) Transaction timeout
	fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10315856.1158657124524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3399?page=all ]

Adrian Brock closed JBAS-3399.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Adrian Brock)

Its only going to throw an error if you access a transacted resource
or you test yourself whether the transaction timed out.

> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:39:01 2006
From: jira-events at jboss.com (tbech (JIRA))
Date: Tue, 19 Sep 2006 05:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3399) Transaction
 timeout fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7135728.1158658741212.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3399?page=comments#action_12343565 ] 
            
tbech commented on JBAS-3399:
-----------------------------

>>  Its only going to throw an error if you access a transacted resource 
and
>> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
>> a) throw an error after timeout 

What I was saying is:
for long transaction - (lets say 10000 gueries/updates, one after another), the exception is not thrown until commit (and the transacted resource is used all the time in this transaction).
This is a bug, (and you agree - "Its only going to throw an error if you access a transacted resource ", but it doesn't throw an exception). So why rejected?


> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:42:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 05:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3667) HotSpot Crashes
In-Reply-To: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19590572.1158658921331.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

Adrian Brock closed JBAS-3667.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Ruel Loehr)

Ruel. These are not JBoss bug. It is a Sun bug.
The error is a seg fault in the garbage collector.

If we let you open such a (non-JBoss) bug report, 
there will be a stream of user bug reports that are the same.

We do not want this.

> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>            Priority: Blocker
>         Attachments: hs_err_pid7517.log
>
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:45:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 05:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3399) Transaction
 timeout fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10374732.1158659101079.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3399?page=comments#action_12343567 ] 
            
Adrian Brock commented on JBAS-3399:
------------------------------------

The use the JBossTM plugin instead of JBossJTA which rollsback the transaction
at transaction timeout.

And please use the forums instead of bug reports to ask for help.

> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:00:01 2006
From: jira-events at jboss.com (Tomaz Cerar (JIRA))
Date: Tue, 19 Sep 2006 06:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-429) Support for
 external security systems
Message-ID: <7019780.1158660001449.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-429?page=comments#action_12343570 ] 
            
Tomaz Cerar commented on JBPM-429:
----------------------------------

is it possible to get this fix ready for 3.1.3 or at least 3.2?

> Support for external security systems
> -------------------------------------
>
>                 Key: JBPM-429
>                 URL: http://jira.jboss.com/jira/browse/JBPM-429
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.0
>         Environment: NA
>            Reporter: Ashwini Kumar
>         Assigned To: Tom Baeyens
>   Original Estimate: 2 minutes
>  Remaining Estimate: 2 minutes
>
> Please change the readAssignmentDelegation method in org.jbpm.jpdl.xml.JpdlXmlReader    to be the following.
> The original method would ignore the class attribute assigned to swimlane assignments and default it to org.jbpm.identity.assignment.ExpressionAssignmentHandler
> Thanks,
> private Delegation readAssignmentDelegation(Element assignmentElement) {
>     Delegation assignmentDelegation = new Delegation();
>     String expression = assignmentElement.attributeValue("expression");
>     if (expression!=null) {
>       assignmentDelegation.setProcessDefinition(processDefinition);
>       String assignmentHandler = assignmentElement.attributeValue("class");
>       if (assignmentHandler != null){
> 		assignmentDelegation.setClassName(assignmentHandler);
>       }
>       else{
> 		assignmentDelegation.setClassName("org.jbpm.identity.assignment.ExpressionAssignmentHandler");	
>       }
>       assignmentDelegation.setConfiguration("<expression>"+expression+"</expression>");
>       
>     } else {
>       assignmentDelegation.read(assignmentElement, this);
>     }
>     return assignmentDelegation;
>   }

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:18:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 06:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33471433.1158661081426.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment:     (was: jdom_example.tar)

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:22:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 06:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18671275.1158661321225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment: jdom_example.tar

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: jdom_example.tar
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:39:01 2006
From: jira-events at jboss.com (srk (JIRA))
Date: Tue, 19 Sep 2006 06:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3667) HotSpot Crashes
In-Reply-To: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18395547.1158662341787.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

srk reopened JBAS-3667:
-----------------------

             

> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>            Priority: Blocker
>         Attachments: hs_err_pid7517.log
>
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 07:37:54 2006
From: jira-events at jboss.com (Mladen Turk (JIRA))
Date: Tue, 19 Sep 2006 07:37:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5891076.1158665874689.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343573 ] 
            
Mladen Turk commented on JBAS-3495:
-----------------------------------

Can someone point me to the place in the source both inside run.jar and shutdown.jar
where optional native .dll can be called as singleton.
This dll will allow together with jbosssvc.exe thread dumps either to the stdout (well stdout.log in service mode)
or to a specified file.

The reason why it is needed in shutdown.jar is to emulate the CTRL+C.

The code that needs to be added is very simple and does noting if the dll is not found,
which is not the case for service mode since both jbosssvc.exe and jbosssch.dll will
be present is that case.

The beauty is that the run.bat is used for service, which means there is no additional
leaning curve for service mode, like there is for other service wrappers.
The overhead of 3MB per service, for an additional cmd.exe is acceptable thought.



> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 07:41:55 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 07:41:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-3667) HotSpot Crashes
Message-ID: <30011937.1158666115398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

Adrian Brock deleted JBAS-3667:
-------------------------------


> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>            Priority: Blocker
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 07:47:57 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 19 Sep 2006 07:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11615610.1158666477221.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343575 ] 
            
Dimitris Andreadis commented on JBAS-3495:
------------------------------------------

You mean?

system/src/main/org/jboss/Main.java

server/scr/main/org/jboss/Shutdown.java
(this one remotely tells the server to shutdown)

> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:41:56 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-82) Release CR7 that
 aligns with AS 4.0.5.GA
Message-ID: <5411313.1158669716890.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release CR7 that aligns with AS 4.0.5.GA
----------------------------------------

                 Key: JBXB-82
                 URL: http://jira.jboss.com/jira/browse/JBXB-82
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Task
            Reporter: Heiko Braun


JBossWS has a dependency on it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:43:55 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:43:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-83) XOPIncludeHandler
 should not work on InputStreams
Message-ID: <16784397.1158669835189.JavaMail.jira@cloud.prod.atl2.jboss.com>

XOPIncludeHandler should not work on InputStreams
-------------------------------------------------

                 Key: JBXB-83
                 URL: http://jira.jboss.com/jira/browse/JBXB-83
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
            Reporter: Heiko Braun


The XOPInclude works on ObjectInputStreams. This disaalows paasing thorugh XB to JBossWS. AFAIK that code piece is obsolete and can be removed.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:45:55 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Tue, 19 Sep 2006 08:45:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3668) EJB Deployment and
	Lookup
Message-ID: <10929330.1158669955877.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB Deployment and Lookup
-------------------------

                 Key: JBAS-3668
                 URL: http://jira.jboss.com/jira/browse/JBAS-3668
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.CR2
            Reporter: madan srinivas
         Assigned To: Bill Burke


I have used JBoss 4.0.4 CR2 and deployed EJB3.0 Entity bean and stateless session bean

Below is the deployed status : 

17:09:11,297 INFO  [JmxKernelAbstraction] installing MBean: persistence.units:ja
r=Test.jar,unitName=manager1 with dependencies:
17:09:11,297 INFO  [JmxKernelAbstraction]       jboss.jca:name=MSSQLDS,service=M
anagedConnectionFactory
17:09:11,344 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Test.
jar,name=FileDetailsClientBean,service=EJB3 with dependencies:
17:09:11,344 INFO  [JmxKernelAbstraction]       persistence.units:jar=Test.jar,u
nitName=manager1
17:09:11,344 INFO  [EJB3Deployer] Deployed: file:/D:/jboss-4.0.4.CR2/server/defa
ult/deploy/Test.jar


But i get following message on jboss server : 

--- MBeans waiting for other MBeans ---
ObjectName: persistence.units:jar=Test.jar,unitName=manager1
  State: NOTYETINSTALLED
  I Depend On:
    jboss.jca:name=MSSQLDS,service=ManagedConnectionFactory
  Depends On Me:
    jboss.j2ee:jar=Test.jar,name=FileDetailsClientBean,service=EJB3

ObjectName: jboss.j2ee:jar=Test.jar,name=FileDetailsClientBean,service=EJB3
  State: NOTYETINSTALLED
  I Depend On:
    persistence.units:jar=Test.jar,unitName=manager1

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.jca:name=MSSQLDS,service=ManagedConnectionFactory
  State: NOTYETINSTALLED
  Depends On Me:
    persistence.units:jar=Test.jar,unitName=manager1


and when i look up the session bean , i get ejb not bound exception

Pls help

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:45:55 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:45:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-84) Anonymous Simple Type
 causes NullPointerException
Message-ID: <13683052.1158669955992.JavaMail.jira@cloud.prod.atl2.jboss.com>

Anonymous Simple Type causes NullPointerException
-------------------------------------------------

                 Key: JBXB-84
                 URL: http://jira.jboss.com/jira/browse/JBXB-84
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
            Reporter: Heiko Braun




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:48:00 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBXB-83) XOPIncludeHandler
 should not work on InputStreams
Message-ID: <3414500.1158670080341.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-83?page=all ]

Heiko Braun deleted JBXB-83:
----------------------------


> XOPIncludeHandler should not work on InputStreams
> -------------------------------------------------
>
>                 Key: JBXB-83
>                 URL: http://jira.jboss.com/jira/browse/JBXB-83
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: Heiko Braun
>
> The XOPInclude works on ObjectInputStreams. This disaalows paasing thorugh XB to JBossWS. AFAIK that code piece is obsolete and can be removed.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:48:00 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBXB-84) Anonymous Simple Type
 causes NullPointerException
Message-ID: <22912456.1158670080457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-84?page=all ]

Heiko Braun deleted JBXB-84:
----------------------------


> Anonymous Simple Type causes NullPointerException
> -------------------------------------------------
>
>                 Key: JBXB-84
>                 URL: http://jira.jboss.com/jira/browse/JBXB-84
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: Heiko Braun
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:49:56 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-82) Release CR7 that
 aligns with AS 4.0.5.GA
In-Reply-To: <5411313.1158669716890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26680982.1158670196371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-82?page=all ]

Heiko Braun updated JBXB-82:
----------------------------

    Assignee: Alexey Loubyansky
    Priority: Critical  (was: Major)

> Release CR7 that aligns with AS 4.0.5.GA
> ----------------------------------------
>
>                 Key: JBXB-82
>                 URL: http://jira.jboss.com/jira/browse/JBXB-82
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>            Priority: Critical
>
> JBossWS has a dependency on it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:55:56 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 08:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-140) Move samples out of
	docs
Message-ID: <19507011.1158670556332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move samples out of docs
------------------------

                 Key: JBESB-140
                 URL: http://jira.jboss.com/jira/browse/JBESB-140
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation, ESB Core, Examples
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
            Priority: Minor
             Fix For: 4.0


The trailblazer needs to be more prominent in the distribution and source. Let's move it out of the docs directory and into it's own, at the same level as docs.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:24:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-39) Add more QA and
	unit tests
Message-ID: <32499154.1158672298917.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-39?page=comments#action_12343578 ] 
            
Mark Little commented on JBESB-39:
----------------------------------

Tom, about 6 weeks prior to release can you go through the code and let the team know which pieces need more coverage?

> Add more QA and unit tests
> --------------------------
>
>                 Key: JBESB-39
>                 URL: http://jira.jboss.com/jira/browse/JBESB-39
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 week, 4 minutes
>  Remaining Estimate: 0 minutes
>
> The Rosetta codebase does not come with a lot of tests. We need a lot more before the beta release and certainly for the 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

        


From jira-events at jboss.com  Tue Sep 19 09:24:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:24:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-126) Remove references to
 LDAP and Processors from diagrams in programmers guide.
In-Reply-To: <12554070.1155119832550.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15095174.1158672299119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-126?page=all ]

Mark Little updated JBESB-126:
------------------------------

    Priority: Minor  (was: Major)

> Remove references to LDAP and Processors from diagrams in programmers guide.
> ----------------------------------------------------------------------------
>
>                 Key: JBESB-126
>                 URL: http://jira.jboss.com/jira/browse/JBESB-126
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:26:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:26:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-65) Tidy-up ESB common
	structure
Message-ID: <20957952.1158672418261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-65?page=all ]

Mark Little reassigned JBESB-65:
--------------------------------

    Assignee: Mark Little  (was: Johan Kumps)

> Tidy-up ESB common structure
> ----------------------------
>
>                 Key: JBESB-65
>                 URL: http://jira.jboss.com/jira/browse/JBESB-65
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>
> - common\src\org\jboss\soa\esb\common\EsbSysProps.java
> 1) Needs name changing, that could imply we need a generic System/Configuration/Property management component/
> 2) Need to standardise naming and casing:
> jbossEsb.mail.smtp.host to (example) jboss.soa.esb.endpoint.email.host this provides a structured / 'packaged' grouped property. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:26:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:26:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-65) Tidy-up ESB common
	structure
Message-ID: <26120633.1158672418462.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-65?page=all ]

Mark Little closed JBESB-65.
----------------------------

    Resolution: Done

This will happen as a result of enforcing a style convention and the refactoring towards the new architecture.

> Tidy-up ESB common structure
> ----------------------------
>
>                 Key: JBESB-65
>                 URL: http://jira.jboss.com/jira/browse/JBESB-65
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> - common\src\org\jboss\soa\esb\common\EsbSysProps.java
> 1) Needs name changing, that could imply we need a generic System/Configuration/Property management component/
> 2) Need to standardise naming and casing:
> jbossEsb.mail.smtp.host to (example) jboss.soa.esb.endpoint.email.host this provides a structured / 'packaged' grouped property. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:26:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:26:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-133) Hosting trailblazer
	on docs site
In-Reply-To: <18695146.1155655940638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29169442.1158672418783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-133?page=all ]

Mark Little updated JBESB-133:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Hosting trailblazer on docs site
> --------------------------------
>
>                 Key: JBESB-133
>                 URL: http://jira.jboss.com/jira/browse/JBESB-133
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>            Priority: Minor
>             Fix For: 4.1
>
>
> We should look at hosting the TB here along with some good writeup on it, diagrams explaining each step of the way, etc...
>  
> http://www.jboss.com/docs/demos

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:55:01 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Tue, 19 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22029711.1158674101129.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-130?page=all ]

Daniel Brum resolved JBESB-130.
-------------------------------

    Resolution: Done

removed reference to 'product' folder from BAT file.

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:00:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14905226.1158674401557.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=comments#action_12343584 ] 
            
Clebert Suconic commented on JBMESSAGING-541:
---------------------------------------------

After JBREM-596 is fixed this task will be just to update Remoting to a stable version with the fix

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 19 10:00:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Tue, 19 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3640) Clustering of the
 quartz-ra.rar failes
In-Reply-To: <21839615.1157995183907.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15500372.1158674401735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3640?page=all ]

Weston Price resolved JBAS-3640.
--------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
       Resolution: Done

Simple fix for volatility property discrepancy. Also added durable and recoverable flags to the QuartzActivationSpec.

> Clustering of the quartz-ra.rar failes
> --------------------------------------
>
>                 Key: JBAS-3640
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3640
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Clustered JBoss where the Quartz-ra.rar is set up for clustering by using any JDBC DataStore
>            Reporter: Kerry Barnes
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> When using a JDBC Data Store for the Quarts-ra.rar, the rar fails by indicating that you cannot have a non-volatile trigger associated with a volatile job.
> The JobStoreCMT file checks to make sure that if the JobDetail is marked as "volatile" the corresponding Trigger is also marked as "volatile." But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to "true" during construction, but the CronTrigger doesn't supply that option at construction and the default setting is to have the volatility set to "false," which is never changed. A mismatch and a problem
> The easiest solution is to modify the JobDetail construction volatility parameter to false so that both instances match. In my tests this generates the desired effect.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:30:03 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Tue, 19 Sep 2006 10:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-139) Add in ftp support
In-Reply-To: <25718589.1158654181382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28293174.1158676203489.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-139?page=all ]

Esteban Schifman resolved JBESB-139.
------------------------------------

    Resolution: Done

Rosetta implemented Ftp downloads with a message listener.  This has now changed to a remote directory polling using FTP.  
This implementation has significantly more overhead but is more resilient to network problems.
Ftp uploads use a traditional local DirectoryPoller and the FtpUpload class as 'action class'

> Add in ftp support
> ------------------
>
>                 Key: JBESB-139
>                 URL: http://jira.jboss.com/jira/browse/JBESB-139
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>          Time Spent: 3 days
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:46:58 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 10:46:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-641) process end
	subprocess cascading
Message-ID: <5668819.1158677218525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-641?page=all ]

Tom Baeyens updated JBPM-641:
-----------------------------

    Fix Version/s: jBPM 3.2 alpha 2
                       (was: jBPM 3.2 alpha 1)

> process end subprocess cascading
> --------------------------------
>
>                 Key: JBPM-641
>                 URL: http://jira.jboss.com/jira/browse/JBPM-641
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> it seems that there is no cascading to subprocesses if a process instance is ended.
> afaik, this should be implemented in the token.end method.  there should be a check on wether there is a subprocessinstance available.  if that is the case, the subprocess instance should be ended.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:50:59 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 10:50:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-746) replace
 NullPointerExceptions with JbpmExceptions
In-Reply-To: <24411573.1157618008353.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10048461.1158677459497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-746?page=all ]

Tom Baeyens closed JBPM-746.
----------------------------

    Resolution: Done

> replace NullPointerExceptions with JbpmExceptions
> -------------------------------------------------
>
>                 Key: JBPM-746
>                 URL: http://jira.jboss.com/jira/browse/JBPM-746
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1
>
>
> replace the NPE's thrown by jbpm with JbpmExceptions.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:50:59 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 10:50:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-732) remove process start
 link for processes without start task
In-Reply-To: <7236390.1155567977653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5640276.1158677459619.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-732?page=all ]

Tom Baeyens updated JBPM-732:
-----------------------------

    Fix Version/s: jBPM 3.2 alpha 2
                       (was: jBPM 3.2 alpha 1)

> remove process start link for processes without start task
> ----------------------------------------------------------
>
>                 Key: JBPM-732
>                 URL: http://jira.jboss.com/jira/browse/JBPM-732
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> a check should be added to the start new process execution list on the home page that verifies if the process has a forms.xml.  if not, the start process link should not be 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

        


From jira-events at jboss.com  Tue Sep 19 10:55:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 10:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-141) Add a glosssary of
	terms
Message-ID: <19331127.1158677701044.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a glosssary of terms
------------------------

                 Key: JBESB-141
                 URL: http://jira.jboss.com/jira/browse/JBESB-141
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Tue Sep 19 11:22:57 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Tue, 19 Sep 2006 11:22:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30428240.1158679377833.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-132?page=all ]

Daniel Brum resolved JBESB-132.
-------------------------------

    Resolution: Done

updated build.xml and template property file to not reference the 'product' folder anymore.

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 12:10:56 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 12:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-85) Add support for base64
 simple types to be XOP optimized
Message-ID: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for base64 simple types to be XOP optimized
-------------------------------------------------------

                 Key: JBXB-85
                 URL: http://jira.jboss.com/jira/browse/JBXB-85
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Feature Request
            Reporter: Heiko Braun


Currently this only works with complex types. In order to be interoperable with MSFT we need to support this.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-6) Make sure the GPD is
 published in the
 local repository when building the jpdl suite and that the copy from the
 local repository is not taken.
Message-ID: <13450250.1158685738065.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make sure the GPD is published in the local repository when building the jpdl suite and that the copy from the local repository is not taken.
---------------------------------------------------------------------------------------------------------------------------------------------

                 Key: GPD-6
                 URL: http://jira.jboss.com/jira/browse/GPD-6
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
    Affects Versions: 3.0.12
            Reporter: Koen Aers
         Assigned To: Koen Aers
            Priority: Critical
             Fix For: 3.0.11




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-6) Make sure the GPD is
 published in the
 local repository when building the jpdl suite and that the copy from the
 local repository is not taken.
In-Reply-To: <13450250.1158685738065.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10812256.1158685738145.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-6?page=all ]

Koen Aers updated GPD-6:
------------------------

        Fix Version/s: 3.0.12
                           (was: 3.0.11)
    Affects Version/s: 3.0.11
                           (was: 3.0.12)

> Make sure the GPD is published in the local repository when building the jpdl suite and that the copy from the local repository is not taken.
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GPD-6
>                 URL: http://jira.jboss.com/jira/browse/GPD-6
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: 3.0.11
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Critical
>             Fix For: 3.0.12
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-7) Generation of simple
 task forms for tasks.
Message-ID: <744949.1158685738218.JavaMail.jira@cloud.prod.atl2.jboss.com>

Generation of simple task forms for tasks.
------------------------------------------

                 Key: GPD-7
                 URL: http://jira.jboss.com/jira/browse/GPD-7
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
          Components: jpdl
    Affects Versions: 3.0.11
            Reporter: Koen Aers
         Assigned To: Koen Aers
            Priority: Critical
             Fix For: 3.0.12




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-7) Generation of simple task
 forms for tasks.
In-Reply-To: <744949.1158685738218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16038802.1158685738295.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-7?page=all ]

Koen Aers closed GPD-7.
-----------------------

    Resolution: Done

This is implemented

> Generation of simple task forms for tasks.
> ------------------------------------------
>
>                 Key: GPD-7
>                 URL: http://jira.jboss.com/jira/browse/GPD-7
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: 3.0.11
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Critical
>             Fix For: 3.0.12
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:27:00 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Tue, 19 Sep 2006 13:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-655) Refactor
	@Service beans
In-Reply-To: <30703765.1153251191416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9041615.1158686820681.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-655?page=comments#action_12343600 ] 
            
Carlo de Wolf commented on EJBTHREE-655:
----------------------------------------

The @Management interface must be registrered into the controller for @Depends to work. Else the dependency will never be satisfied from the controller's point of view.

That means that the controller will call create/start/stop/destroy on the @Management interface, resulting in calls to the container which has already done that.

At that point the create/start/stop/destroy methods in both @Management and the bean become a double edged sword because either it's the management interface getting c/s/s/d-ed or it's the container getting c/s/s/d-ed.

> Refactor @Service beans
> -----------------------
>
>                 Key: EJBTHREE-655
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-655
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Refactor @Service beans to fix a number of problems:
> * magic methods for lifecycle methods:
>   - create/start/stop/destroy
> * lifecycle methods are not required to be in @Management (MBean) interface.
> * @Management interface is not registered with the ServiceController (Controller in MC land).  It *IS* registered as a regular MBean though.
> * If lifecycle methods exist on @Management interface, they must be intercepted on the container so that the appropriate Controler start/stop is done on the container.  This would mean that you have to specify a <bind> in the Service aspect domain in ejb3-interceptors-aop.xml

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:28:56 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Tue, 19 Sep 2006 13:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-138) trailblazer demo has
 problems in some locales
In-Reply-To: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12475903.1158686936888.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-138?page=all ]

Kurt Stam updated JBESB-138:
----------------------------

    Description: 
There a re parsing problems when converting a string (1000,00) to Double.

There was another formatting issue in the CustomerAdapter.java. 

  was:There a re parsing problems when converting a string (1000,00) to Double.


> trailblazer demo has problems in some locales
> ---------------------------------------------
>
>                 Key: JBESB-138
>                 URL: http://jira.jboss.com/jira/browse/JBESB-138
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Kurt Stam
>         Attachments: patch.txt
>
>
> There a re parsing problems when converting a string (1000,00) to Double.
> There was another formatting issue in the CustomerAdapter.java. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:30:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 13:30:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
In-Reply-To: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27735277.1158687057359.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-89?page=all ]

Clebert Suconic closed JBSER-89.
--------------------------------

    Resolution: Done

> StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSER-89
>                 URL: http://jira.jboss.com/jira/browse/JBSER-89
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.1 GA, 1.0.2 GA
>            Reporter: Manik Surtani
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA
>
>
> See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:30:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 13:30:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
In-Reply-To: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6619368.1158687057531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSER-89?page=comments#action_12343601 ] 
            
Clebert Suconic commented on JBSER-89:
--------------------------------------

I have imported these tests into jboss-serialization code.


The fix is in place also.

> StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSER-89
>                 URL: http://jira.jboss.com/jira/browse/JBSER-89
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.1 GA, 1.0.2 GA
>            Reporter: Manik Surtani
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA
>
>
> See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:37:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 13:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSER-86) The distribution jar
 manifest contains obsolete version information
In-Reply-To: <7606513.1155111192460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5054190.1158687477338.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-86?page=all ]

Clebert Suconic closed JBSER-86.
--------------------------------

    Resolution: Done

> The distribution jar manifest contains obsolete version information
> -------------------------------------------------------------------
>
>                 Key: JBSER-86
>                 URL: http://jira.jboss.com/jira/browse/JBSER-86
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.2 GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.3 GA
>
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: JBoss Inc.
> version: 1.0.0.RC1
> Main-Class: org.jboss.serial.Version

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:05:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 14:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-547) Upgrade
 JBossSerialization to 1.0.3.GA
Message-ID: <24696517.1158689157470.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade JBossSerialization to 1.0.3.GA
--------------------------------------

                 Key: JBMESSAGING-547
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.0.1.CR5


I will do it as soon as the release is out.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:10:00 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Tue, 19 Sep 2006 14:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-138) trailblazer demo
 has problems in some locales
In-Reply-To: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3465156.1158689400788.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-138?page=all ]

Kurt Stam resolved JBESB-138.
-----------------------------

    Resolution: Done

> trailblazer demo has problems in some locales
> ---------------------------------------------
>
>                 Key: JBESB-138
>                 URL: http://jira.jboss.com/jira/browse/JBESB-138
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Kurt Stam
>         Attachments: patch.txt
>
>
> There a re parsing problems when converting a string (1000,00) to Double.
> There was another formatting issue in the CustomerAdapter.java. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:11:55 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Tue, 19 Sep 2006 14:11:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBIDE-365) Changing hostname
 in server
 config (JBoss 'Server Editor'), breaks twiddle monitoring for server
 startup
In-Reply-To: <24852255.1157723849263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8381562.1158689515085.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-365?page=all ]

Robert Stryker resolved JBIDE-365.
----------------------------------

    Fix Version/s: 2.0.0.Beta3
       Resolution: Done

Changing host in the editor correctly modifies the launch configuration attributes now. 

> Changing hostname in server config (JBoss 'Server Editor'), breaks twiddle monitoring for server startup
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-365
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-365
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200 (eclipse 3.2)
> JBoss-4.0.4.GA
> jdk1.5.0_06
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>             Fix For: 2.0.0.Beta3
>
>
> Changing hostname in server config view breaks twiddle monitoring for server startup
> Posible cause, maybe JBossIDE (?JBossAS Adapter?) access to twiddle script doesn't use yet
> $WORKSPACE\.metadata\.plugins\org.eclipse.wst.server.core\servers.xml
> to set -s option on the twiddle script.
> Also, changing hostname doesn't change Launch configuration, where argument '--host=localhost' is set by default.
> file: $WORKSPACE\.metadata\.plugins\org.eclipse.debug.core\.launches\JBoss-4.0.4.GA.launch

-- 
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

       



From jira-events at jboss.com  Tue Sep 19 14:13:56 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Tue, 19 Sep 2006 14:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBIDE-362) NPE from
 org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
In-Reply-To: <24905392.1157642431741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18920376.1158689636810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-362?page=all ]

Robert Stryker resolved JBIDE-362.
----------------------------------

    Fix Version/s: 2.0.0.Beta2
       Resolution: Done

check for blank files added. 

> NPE from org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
> -----------------------------------------------------------------------------------
>
>                 Key: JBIDE-362
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-362
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Robert Stryker
>             Fix For: 2.0.0.Beta2
>
>
> Just thought I'd report this.
> java.lang.NullPointerException
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports(ArchiveModuleFactory.java:64)
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.acceptAddition(ArchiveModuleFactory.java:33)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory$1.visit(JBossModuleFactory.java:88)
> at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:105)
> at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
> at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:103)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:87)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.cacheModules(JBossModuleFactory.java:86)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.getModules(JBossModuleFactory.java:66)
> at org.eclipse.wst.server.core.internal.ModuleFactory.getModules(ModuleFactory.java:133)
> at org.eclipse.wst.server.core.ServerUtil.getModules(ServerUtil.java:285)
> at org.eclipse.wst.server.core.ServerUtil.getModule(ServerUtil.java:52)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.gatherModuleReference(ComponentDeployable.java:126)
> at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.gatherModuleReference(J2EEFlexProjDeployable.java:466)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.getModules(ComponentDeployable.java:113)
> at org.eclipse.jst.server.tomcat.core.internal.TomcatServer.getChildModules(TomcatServer.java:212)
> at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2174)
> at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:2334)
> at org.eclipse.wst.server.core.internal.Server.visit(Server.java:2315)
> at org.eclipse.wst.server.core.internal.Server.shouldRestart(Server.java:805)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableLabelProvider.getColumnText(ServerTableLabelProvider.java:183)
> at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:309)
> at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:95)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:849)
> at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:465)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1955)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:753)
> at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
> at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
> at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
> at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
> at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
> at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
> at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableViewer.<init>(ServerTableViewer.java:240)
> at org.eclipse.wst.server.ui.internal.view.servers.ServersView.createPartControl(ServersView.java:89)
> at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
> at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
> at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
> at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:290)
> at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:525)
> at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:140)
> at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268)
> at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
> at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:394)
> at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1144)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:620)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:532)
> at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:562)
> at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:244)
> at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:815)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3284)
> at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:957)
> at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:941)
> at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3408)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3406)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem.select(PerspectiveBarContributionItem.java:123)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem$1.widgetSelected(PerspectiveBarContributionItem.java:92)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3166)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2842)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
> 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:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:26:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11101043.1158690361227.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343605 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Deadlock:

2006-09-18 22:06:46,109 6281  TRACE [org.jboss.jms.server.container.ServerLogInterceptor] @main invoking ConsumerAdvised->ConsumerEndpoint[-2147483626].close()
2006-09-18 22:06:46,109 6281  TRACE [org.jboss.jms.server.endpoint.ServerConsumerEndpoint] @Thread-3 ConsumerEndpoint[-2147483626] receives Reference[1537]:RELIABLE for delivery

The main thread tries to close the ConsumerEndpoint, grabs ConsumerEndpoint's main lock and gets stuck trying to get Channel->Router->receivers' lock, in process of removing the ConsumerEndpoint from the channel.
Thread-3 has  Channel->Router->receivers' lock and gets stuck trying to grab ConsumerEndpoint's main lock.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:40:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28036489.1158691201333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov updated JBMESSAGING-546:
----------------------------------------

    Comment: was deleted

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:40:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33277498.1158691201450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343607 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Deadlock:

2006-09-18 22:06:46,109 6281 TRACE [org.jboss.jms.server.container.ServerLogInterceptor] @main invoking ConsumerAdvised->ConsumerEndpoint[-2147483626].close()
2006-09-18 22:06:46,109 6281 TRACE [org.jboss.jms.server.endpoint.ServerConsumerEndpoint] @Thread-3 ConsumerEndpoint[-2147483626] receives Reference[1537]:RELIABLE for delivery



> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:40:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21710069.1158691201578.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343608 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Increased tracing resolution.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-502) Create a MSSQL
 persistence manager config
In-Reply-To: <29492968.1155039912398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6151663.1158692217961.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-502?page=all ]

Ovidiu Feodorov closed JBMESSAGING-502.
---------------------------------------


> Create a MSSQL persistence manager config
> -----------------------------------------
>
>                 Key: JBMESSAGING-502
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-502
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Luc Texier
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-90) Generate a
 correct manifest file
Message-ID: <13021367.1158692218158.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-90?page=all ]

Ovidiu Feodorov closed JBMESSAGING-90.
--------------------------------------


> Generate a correct manifest file
> --------------------------------
>
>                 Key: JBMESSAGING-90
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-90
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Ovidiu Feodorov
>         Assigned To: Alex Fu
>             Fix For: 1.0.0 beta
>
>
> Generate a manifest that contains correct versioning information when creating distribution archives (jars/sars)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-278)
	JMSXDeliveryCount support
Message-ID: <4322425.1158692218692.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-278?page=all ]

Ovidiu Feodorov closed JBMESSAGING-278.
---------------------------------------


> JMSXDeliveryCount support
> -------------------------
>
>                 Key: JBMESSAGING-278
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-278
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Ovidiu Feodorov
>         Assigned To: Alex Fu
>             Fix For: 1.0.0
>
>
> While running TCK, tests fail because the current TCK version doesn't handle well  JMSXDeliveryCount. The temporary solution is to disable Messaging support for it (JBossMessage.gettPropertyNames() just doesn't return it anymore).
> This happens because TCK thinks all properties returned by Message.getPropertyNames() as String properties, tries to getStringProperty("JMSXDeliveryCount"), gets null because the correct way to retrieve JMSXDeliveryCount is getIntProperty() and dies with NullPointerException.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-311) Add destination
 deployment params test
Message-ID: <27877407.1158692219118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-311?page=all ]

Ovidiu Feodorov closed JBMESSAGING-311.
---------------------------------------


> Add destination deployment params test
> --------------------------------------
>
>                 Key: JBMESSAGING-311
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-311
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Alex Fu
>             Fix For: 1.0.1.CR1
>
>
> A bug was fixed just before 1.0 release where destination params were being validated on each setXXX call, causing destinations to de deployed with the wrong params.
> This has been fixed, but test needs to be added to prevent this happening again.
> Imagine I have queue with fullSize = 100, pageSize = 50, downCacheSize = 50
> I then want to set the queue to have fullSize = 1000, pageSize = 500, downCacheSize = 500
> If I attempt to set the queue's downCacheSize to 500 then it will fail to set it, since the downCacheSize would temporarily be more than fullSize. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 15:00:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 15:00:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25312481.1158692454744.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343610 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

the code should contain sufficient trace statements to identify and fix the deadlock, when it occurs.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 15:00:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 15:00:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15412864.1158692454896.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov updated JBMESSAGING-546:
----------------------------------------

    Priority: Major  (was: Critical)

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 16:07:58 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Tue, 19 Sep 2006 16:07:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3554) Upgrade JBoss AS
 to use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16354846.1158696478637.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3554?page=comments#action_12343616 ] 
            
Stan Silvert commented on JBAS-3554:
------------------------------------

MyFaces 1.1.4 is finally out.  As long as my integration tests pass, I should be able to have it into 4.0.5 within 24 hours.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 16:09:59 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Tue, 19 Sep 2006 16:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28849079.1158696599659.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Stan Silvert updated JBAS-3554:
-------------------------------

    Fix Version/s:     (was: JBossAS-5.0.0.Beta)

Removed 5.0.0 Beta as "Fix Version".  5.0.0 uses glassfish CDDL JSF instead of MyFaces.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:28:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 19 Sep 2006 17:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2614) Add a stress test of
 region activation/inactivation under load
Message-ID: <5661937.1158701281214.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2614?page=all ]

Brian Stansberry updated JBAS-2614:
-----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Add a stress test of region activation/inactivation under load
> --------------------------------------------------------------
>
>                 Key: JBAS-2614
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2614
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> There are already tests of this in the JBossCache testsuite, but a test that involves the JBossCacheManager layer as well would be good.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:36:01 2006
From: jira-events at jboss.com (Keith Gregory (JIRA))
Date: Tue, 19 Sep 2006 17:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3670)
 org.jboss.axis.ConfigurationException: No engine configuration file
Message-ID: <7732126.1158701761366.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.axis.ConfigurationException: No engine configuration file
-------------------------------------------------------------------

                 Key: JBAS-3670
                 URL: http://jira.jboss.com/jira/browse/JBAS-3670
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Keith Gregory
         Assigned To: Thomas Diesler
            Priority: Minor


The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.

Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.

The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.

The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:36:01 2006
From: jira-events at jboss.com (Keith Gregory (JIRA))
Date: Tue, 19 Sep 2006 17:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3671)
 org.jboss.axis.ConfigurationException: No engine configuration file
Message-ID: <13187415.1158701761524.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.axis.ConfigurationException: No engine configuration file
-------------------------------------------------------------------

                 Key: JBAS-3671
                 URL: http://jira.jboss.com/jira/browse/JBAS-3671
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Keith Gregory
         Assigned To: Thomas Diesler
            Priority: Minor


The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.

Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.

The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.

The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:46:01 2006
From: jira-events at jboss.com (Keith Gregory (JIRA))
Date: Tue, 19 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3671)
 org.jboss.axis.ConfigurationException: No engine configuration file
In-Reply-To: <13187415.1158701761524.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18041774.1158702361342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3671?page=comments#action_12343626 ] 
            
Keith Gregory commented on JBAS-3671:
-------------------------------------

Looking at the 4.0.4 GA source tree, this has not been fixed.

> org.jboss.axis.ConfigurationException: No engine configuration file
> -------------------------------------------------------------------
>
>                 Key: JBAS-3671
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3671
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Keith Gregory
>         Assigned To: Thomas Diesler
>            Priority: Minor
>
> The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.
> Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.
> The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.
> The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
> new Service(new FileProvider("META-INF/axis-client-config.xml"))

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:52:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 19 Sep 2006 17:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-326) Create the
 concept of a
 "priority queue" to speed execution of certain remote method invocations
Message-ID: <14449729.1158702721371.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-326?page=comments#action_12343627 ] 
            
Brian Stansberry commented on JBCACHE-326:
------------------------------------------

I'm not 100% sure, but this likely won't improve much for state transfer once FLUSH is done.  I guess the benefit would be if block call were stuck in the jg up queue because a preceding repl msg is held up by a lock conflict.  Probably we should wait and see what comes out of implementing block() .

> Create the concept of a "priority queue" to speed execution of certain remote method invocations
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-326
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-326
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0
>
>
> Change the handling of requests in JBossCache (another  interceptor on top of ReplicationInterceptor): 
> - Create 2 queues (of MethodCall objects), one thread for each queue 
> - The regular MethodCalls like put(), remove() etc go into the  default queue (A), where they are processed according to order (FIFO) 
> - The special calls like block(), _getState(), commit() or acks  for PREPARE/COMMIT calls go into the other (priority) queue (B),  these calls *CAN* be received out of sequence 
> - This way, an _getState() would always be processed and  would be able to (1) stop the processing of queue A and (2) force- release any locks held 
>   by on the tree.
> _ This way commit() calls can promptly release locks, without having to wait behind other prepare 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

        


From jira-events at jboss.com  Tue Sep 19 17:54:01 2006
From: jira-events at jboss.com (chi lin (JIRA))
Date: Tue, 19 Sep 2006 17:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBADMCON-149) Support JBoss
	Messaging
Message-ID: <24165467.1158702841307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support JBoss Messaging
-----------------------

                 Key: JBADMCON-149
                 URL: http://jira.jboss.com/jira/browse/JBADMCON-149
             Project: JBoss Admin Console
          Issue Type: Feature Request
          Components: General Console
    Affects Versions: 1.1 alpha
            Reporter: chi lin
         Assigned To: chi lin
             Fix For: 1.1 alpha


Since JBoss Messaging will be the default JMS provider for JBoss AS 5.x, the Admin Console should support JBoss Messaging instead of (or in addition to) JBossMQ. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:02:01 2006
From: jira-events at jboss.com (chi lin (JIRA))
Date: Tue, 19 Sep 2006 18:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBADMCON-149) Support JBoss
	Messaging
In-Reply-To: <24165467.1158702841307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31666934.1158703321256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-149?page=all ]

chi lin updated JBADMCON-149:
-----------------------------

    Attachment: SupportJBossMessaging.pdf

The attached file contains a mini-design and work break-down to support JBoss Messaging. Your comments are welcome!

> Support JBoss Messaging
> -----------------------
>
>                 Key: JBADMCON-149
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-149
>             Project: JBoss Admin Console
>          Issue Type: Feature Request
>          Components: General Console
>    Affects Versions: 1.1 alpha
>            Reporter: chi lin
>         Assigned To: chi lin
>             Fix For: 1.1 alpha
>
>         Attachments: SupportJBossMessaging.pdf
>
>
> Since JBoss Messaging will be the default JMS provider for JBoss AS 5.x, the Admin Console should support JBoss Messaging instead of (or in addition to) JBossMQ. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:10:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 18:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBSER-88) Create
	DataContainer.clone method
In-Reply-To: <10710529.1156790206090.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29786390.1158703801260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-88?page=all ]

Clebert Suconic reopened JBSER-88:
----------------------------------

             

> Create DataContainer.clone method
> ---------------------------------
>
>                 Key: JBSER-88
>                 URL: http://jira.jboss.com/jira/browse/JBSER-88
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.1.0 Beta, 1.0.3 GA
>
>
> DataContainer was not meant to be multi-thread. However if you want to use Datacontainer as an object factory it would be possible to reuse its internal data in a clone operation, and then use the result in a multi-thread environment.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:10:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 18:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-88) DataContainer.clone
	method
In-Reply-To: <10710529.1156790206090.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30246168.1158703801369.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-88?page=all ]

Clebert Suconic updated JBSER-88:
---------------------------------

    Summary: DataContainer.clone method  (was: Create DataContainer.clone method)

> DataContainer.clone method
> --------------------------
>
>                 Key: JBSER-88
>                 URL: http://jira.jboss.com/jira/browse/JBSER-88
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.1.0 Beta, 1.0.3 GA
>
>
> DataContainer was not meant to be multi-thread. However if you want to use Datacontainer as an object factory it would be possible to reuse its internal data in a clone operation, and then use the result in a multi-thread environment.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:10:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 18:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSER-88) DataContainer.clone
	method
In-Reply-To: <10710529.1156790206090.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32584975.1158703801495.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-88?page=all ]

Clebert Suconic closed JBSER-88.
--------------------------------

    Resolution: Done

> DataContainer.clone method
> --------------------------
>
>                 Key: JBSER-88
>                 URL: http://jira.jboss.com/jira/browse/JBSER-88
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA, 1.1.0 Beta
>
>
> DataContainer was not meant to be multi-thread. However if you want to use Datacontainer as an object factory it would be possible to reuse its internal data in a clone operation, and then use the result in a multi-thread environment.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:30:01 2006
From: jira-events at jboss.com (Peter Johnson (JIRA))
Date: Tue, 19 Sep 2006 18:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBADMCON-149) Support JBoss
	Messaging
In-Reply-To: <24165467.1158702841307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31397318.1158705001237.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-149?page=all ]

Peter Johnson updated JBADMCON-149:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972762

> Support JBoss Messaging
> -----------------------
>
>                 Key: JBADMCON-149
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-149
>             Project: JBoss Admin Console
>          Issue Type: Feature Request
>          Components: General Console
>    Affects Versions: 1.1 alpha
>            Reporter: chi lin
>         Assigned To: chi lin
>             Fix For: 1.1 alpha
>
>         Attachments: SupportJBossMessaging.pdf
>
>
> Since JBoss Messaging will be the default JMS provider for JBoss AS 5.x, the Admin Console should support JBoss Messaging instead of (or in addition to) JBossMQ. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 19:00:01 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Tue, 19 Sep 2006 19:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11622762.1158706801266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Stan Silvert resolved JBAS-3554.
--------------------------------

    Resolution: Done

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 19:42:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 19:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28904112.1158709321250.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343635 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Can't get it to repeat, with the new tracing code. Repeat it in a loop.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 20:55:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 20:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29175.1158713701092.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov closed JBMESSAGING-542.
---------------------------------------

    Resolution: Done

Fixed by modifying the SessionAspect to send to server accumulated AUTO and DUPS_OK acknowledgments on closing, and then skip postDeliver() to avoid passing through a "closed" ClosedInterceptor.

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 00:41:53 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 00:41:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1043091.1158727313489.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343639 ] 
            
Tom  Elrod commented on JBREM-596:
----------------------------------

Have updated code so that client invoker is responsible for handling lease management for all Clients using that client invoker.  The org.jboss.test.remoting.lease.socket.multiple package test case is passing now.

The main benefit for this (other than fixing original bug) is that instead of having a thread per Client doing lease ping, will only be one thread per client invoker (regardless of number of Clients using that client invoker).  

This change does raise some issues with regards to some of the more obscure behaviors, which have been listed in forum post - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972805#3972805

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 00:43:54 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 00:43:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8916942.1158727434467.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343640 ] 
            
Tom  Elrod commented on JBREM-596:
----------------------------------

Clebert, can you verify this fix for messaging?

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 02:29:56 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Wed, 20 Sep 2006 02:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3672) EJB3.0 session bean
 look up and data source configuration
Message-ID: <21983529.1158733796302.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3.0 session bean look up and data source configuration
---------------------------------------------------------

                 Key: JBAS-3672
                 URL: http://jira.jboss.com/jira/browse/JBAS-3672
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.CR2
         Environment: Windows 2000 Professional , JBoss 4.0.4CR2, SQL Server 2005
            Reporter: madan srinivas
         Assigned To: Bill Burke


I have deployed datasource using mssqlds.xml in jboss/server/default/deploy

sqljdbc.jar has been placed in jboss/server/default/lib directory

driver class is com.microsoft.sqlserver.jdbc.SQLServerDriver but if i use it i get Wrong driver class error 

hence i changed it to com.microsoft.jdbc.sqlserver.SQLServerDriver but irt fails to register the river 

Error : 
Caused by: org.jboss.resource.JBossResourceException: Failed to register driver
for: com.microsoft.jdbc.sqlserver.SQLServerDriver; - nested throwable: (java.lan
g.ClassNotFoundException: No ClassLoaders found for: com.microsoft.jdbc.sqlserve
r.SQLServerDriver)

Server output on console for EJB deployment : 

But when i do jndi look up i get received timed out error , pls help

11:47:06,356 INFO  [NamingHelper] JNDI InitialContext properties:{java.naming.fa
ctory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.p
kgs=org.jboss.naming:org.jnp.interfaces}
11:47:06,403 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Test.
jar,name=FileDetailsClientBean,service=EJB3 with dependencies:
11:47:06,403 INFO  [JmxKernelAbstraction]       persistence.units:jar=Test.jar,u
nitName=manager1
11:47:06,653 INFO  [EJBContainer] STARTED EJB: com.hqs.ppsadvantage.ejb.FileDeta
ilsClientBean ejbName: FileDetailsClientBean
11:47:06,731 INFO  [EJB3Deployer] Deployed: file:/D:/jboss-4.0.4.CR2/server/defa
ult/deploy/Test.jar

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 03:27:57 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 03:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3672) EJB3.0 session bean
 look up and data source configuration
In-Reply-To: <21983529.1158733796302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18875163.1158737277110.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3672?page=all ]

Dimitris Andreadis closed JBAS-3672.
------------------------------------

    Resolution: Rejected

Please use the forums for this type of questions.

> EJB3.0 session bean look up and data source configuration
> ---------------------------------------------------------
>
>                 Key: JBAS-3672
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3672
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>         Environment: Windows 2000 Professional , JBoss 4.0.4CR2, SQL Server 2005
>            Reporter: madan srinivas
>         Assigned To: Bill Burke
>
> I have deployed datasource using mssqlds.xml in jboss/server/default/deploy
> sqljdbc.jar has been placed in jboss/server/default/lib directory
> driver class is com.microsoft.sqlserver.jdbc.SQLServerDriver but if i use it i get Wrong driver class error 
> hence i changed it to com.microsoft.jdbc.sqlserver.SQLServerDriver but irt fails to register the river 
> Error : 
> Caused by: org.jboss.resource.JBossResourceException: Failed to register driver
> for: com.microsoft.jdbc.sqlserver.SQLServerDriver; - nested throwable: (java.lan
> g.ClassNotFoundException: No ClassLoaders found for: com.microsoft.jdbc.sqlserve
> r.SQLServerDriver)
> Server output on console for EJB deployment : 
> But when i do jndi look up i get received timed out error , pls help
> 11:47:06,356 INFO  [NamingHelper] JNDI InitialContext properties:{java.naming.fa
> ctory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.p
> kgs=org.jboss.naming:org.jnp.interfaces}
> 11:47:06,403 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Test.
> jar,name=FileDetailsClientBean,service=EJB3 with dependencies:
> 11:47:06,403 INFO  [JmxKernelAbstraction]       persistence.units:jar=Test.jar,u
> nitName=manager1
> 11:47:06,653 INFO  [EJBContainer] STARTED EJB: com.hqs.ppsadvantage.ejb.FileDeta
> ilsClientBean ejbName: FileDetailsClientBean
> 11:47:06,731 INFO  [EJB3Deployer] Deployed: file:/D:/jboss-4.0.4.CR2/server/defa
> ult/deploy/Test.jar

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 04:17:54 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 04:17:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21562578.1158740274463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Dimitris Andreadis reopened JBAS-3554:
--------------------------------------

             
The 1.1.4 libraries in the repository should not contain the version numbers in the filenames, so I corrected that.

In fact, I see the same mistake is made in the myfaces-1.1.3 version, but I didn't correct this there, since I'm not sure where else this is already used.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From c12 at fullmailmarket.com  Wed Sep 20 04:36:27 2006
From: c12 at fullmailmarket.com (Hostex.cl)
Date: Wed, 20 Sep 2006 04:36:27 -0400
Subject: [jboss-jira] WebHosting Profesional.
Message-ID: <200609200836.k8K8aTHM008232@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060920/cdfc88b9/attachment.html 

From jira-events at jboss.com  Wed Sep 20 05:38:01 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Wed, 20 Sep 2006 05:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3674) service
 MetricsLookup dont show invocations
Message-ID: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>

service MetricsLookup dont show invocations
-------------------------------------------

                 Key: JBAS-3674
                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-3.2.7 Final
         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
jdk1.5.0_06
Intel Xeon CPU
            Reporter: abo abo


on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.

metrics-service.xml:
=============================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->

<server>

  <classpath codebase="lib"
             archives="jboss.jar"/>

  <!-- ==================================================================== -->
  <!-- Metrics Service                                                    -->
  <!-- ==================================================================== -->

  <mbean code="org.jboss.ejb.plugins.MetricsLookup"
          name="jboss:service=MetricsLookup">
          <attribute name="SanityInterval">120000</attribute>
          <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
          <attribute name="EjbPattern">*</attribute>
          <attribute name="MethodPattern">*</attribute>
          <attribute name="ShowParams">true</attribute>
  </mbean>

</server>
=============================================================


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:35:01 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-142) Add support for
 processing
 messages received by Listeners through a pipeline of action processors.
Message-ID: <22412365.1158748501271.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for processing messages received by Listeners through a pipeline of action processors.
--------------------------------------------------------------------------------------------------

                 Key: JBESB-142
                 URL: http://jira.jboss.com/jira/browse/JBESB-142
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0
            Reporter: Tom Fennelly
         Assigned To: Mark Little
             Fix For: 4.0


Rosetta supported a 1:1 listener to action handler message processing model.  We need to be able to push the messages into a pipeline of action processors.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:38:00 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-142) Add support for
 processing
 messages received by Listeners through a pipeline of action processors.
In-Reply-To: <22412365.1158748501271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29476344.1158748680684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-142?page=all ]

Tom Fennelly closed JBESB-142.
------------------------------

    Resolution: Done

See http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

> Add support for processing messages received by Listeners through a pipeline of action processors.
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBESB-142
>                 URL: http://jira.jboss.com/jira/browse/JBESB-142
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0
>            Reporter: Tom Fennelly
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>   Original Estimate: 1 week, 3 days
>  Remaining Estimate: 1 week, 3 days
>
> Rosetta supported a 1:1 listener to action handler message processing model.  We need to be able to push the messages into a pipeline of action processors.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:40:00 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-143) Add Action
 Pipelining info to the Programmers Guide
Message-ID: <31051559.1158748800070.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add Action Pipelining info to the Programmers Guide
---------------------------------------------------

                 Key: JBESB-143
                 URL: http://jira.jboss.com/jira/browse/JBESB-143
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0
            Reporter: Tom Fennelly
         Assigned To: Mark Little
             Fix For: 4.0


Move Action Processing Pipeline info from the Wiki to the programmers guide.

Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:40:00 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-143) Add Action
 Pipelining info to the Programmers Guide
In-Reply-To: <31051559.1158748800070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6626236.1158748800223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-143?page=all ]

Tom Fennelly reassigned JBESB-143:
----------------------------------

    Assignee: Tom Fennelly  (was: Mark Little)

> Add Action Pipelining info to the Programmers Guide
> ---------------------------------------------------
>
>                 Key: JBESB-143
>                 URL: http://jira.jboss.com/jira/browse/JBESB-143
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0
>            Reporter: Tom Fennelly
>         Assigned To: Tom Fennelly
>             Fix For: 4.0
>
>
> Move Action Processing Pipeline info from the Wiki to the programmers guide.
> Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:53:01 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-142) Add support for
 processing
 messages received by Listeners through a pipeline of action processors.
In-Reply-To: <22412365.1158748501271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15499004.1158749581330.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-142?page=all ]

Tom Fennelly reassigned JBESB-142:
----------------------------------

    Assignee: Tom Fennelly  (was: Mark Little)

> Add support for processing messages received by Listeners through a pipeline of action processors.
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBESB-142
>                 URL: http://jira.jboss.com/jira/browse/JBESB-142
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0
>            Reporter: Tom Fennelly
>         Assigned To: Tom Fennelly
>             Fix For: 4.0
>
>   Original Estimate: 1 week, 3 days
>          Time Spent: 1 week, 3 days
>  Remaining Estimate: 0 minutes
>
> Rosetta supported a 1:1 listener to action handler message processing model.  We need to be able to push the messages into a pipeline of action processors.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 07:21:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Wed, 20 Sep 2006 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3674) service MetricsLookup
 dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12607200.1158751261187.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3674?page=all ]

Adrian Brock closed JBAS-3674.
------------------------------

    Resolution: Out of Date

Use jsr77

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 07:56:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 07:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-5) Leverage existing tools
Message-ID: <12277072.1158753360142.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-5?page=all ]

Mark Little closed JBESB-5.
---------------------------

    Resolution: Out of Date

> Leverage existing tools
> -----------------------
>
>                 Key: JBESB-5
>                 URL: http://jira.jboss.com/jira/browse/JBESB-5
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBI Core
>            Reporter: Joseph Marques
>         Assigned To: Mark Little
>
> Why doesn't JBoss start from and extend one of the current open source ESB solutions such as Mule or ServiceMix (the latter of which has a core JBI 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

        


From jira-events at jboss.com  Wed Sep 20 07:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 07:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-144) Add unit tests for
 new EPR and messaging classes.
Message-ID: <3775013.1158753481061.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add unit tests for new EPR and messaging classes.
-------------------------------------------------

                 Key: JBESB-144
                 URL: http://jira.jboss.com/jira/browse/JBESB-144
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep 20 08:00:58 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Wed, 20 Sep 2006 08:00:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-710) Cleanup E-EJB3
 package/code/logging
Message-ID: <20336427.1158753658361.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cleanup E-EJB3 package/code/logging
-----------------------------------

                 Key: EJBTHREE-710
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-710
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC9 - FD
            Reporter: Christian Bauer
            Priority: Blocker


This is E-EJB3 RC9. The following issues are not minor, they would make me feel uneasy if I was a user:

1. The bundled embedded-jboss-beans.xml uses xmlns="urn:jboss:bean-deployer" and everybody gets a nice WARN on startup that xmlns="urn:jboss:bean-deployer:2.0" should be used. Change that in the distributed configuration file.

2. [java] 13:40:10,676  WARN Ejb3Configuration:104 - Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null. It's OK to warn users that something is not right, but if something is not right in our distribution there should be a note in the README or something that tells me as a user that this is OK for the moment. Like a link to a JIRA issue.

3. [java] 13:44:59,381  WARN JBossTimerServiceFactory:112 - TIMER SERVICE IS NOT INSTALLED -- Uh, yes, because I don't want it. Find a way for users to disable this warning. I don't see any way to disable the timer service in embedded-jboss-beans.xml and I don't want the .rar and .jar in my libs.

4. In RC9 there is code that prints debugging stuff on STDOUT:

     [java] lookup 
     [java]   UserTransaction: org.jboss.ejb3.embedded.UserTransactionImpl
     [java]   MessageHandlerBean: org.jnp.interfaces.NamingContext  

This is triggered by EJB3StandaloneBootstrap.scanClasspath("helloworld-ejb3/build"), please remove from code...



-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:18:01 2006
From: jira-events at jboss.com (Mladen Turk (JIRA))
Date: Wed, 20 Sep 2006 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9415354.1158754681242.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343649 ] 
            
Mladen Turk commented on JBAS-3495:
-----------------------------------

Right, if those are the main entry classes for run/shutdown.
The new shutdown would have additional Send ConsoleCtrlEvent to the running service,
just like if the user would hit CRTL+C in the 'normal window'.

BTW, do we have a daily SVN snapshots for the trunk?


> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:18:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Wed, 20 Sep 2006 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27770935.1158754681414.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-98?page=comments#action_12343650 ] 
            
Jonathan Halliday commented on JBTM-98:
---------------------------------------

Per above forum reference, issue was reported as problem with Xid length when using Oracle 10g OCI JDBC driver, with suggested fix:

"The driver does not like the global and branch qualifier IDs if they are not padded to 64 bytes. I have modified the methods XidImple.getGlobalTransactionId() and XidImple.getBranchQualifier() to return a padded array of 64 bytes."

Attempted to reproduce the issue using Oracle 10g release 2 on linux for both client and server. Unable to reproduce issue, XA transaction worked ok.  Oracle may have fixed issue in their driver by 10g, so I also attempted to reproduce the issue using Oracle 9i release 2 client/server on linux. Still worked.

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:21:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Wed, 20 Sep 2006 08:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17969937.1158754861299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-98?page=all ]

Jonathan Halliday resolved JBTM-98.
-----------------------------------

    Resolution: Cannot Reproduce Bug


Unable to reproduce bug. no code changes made.

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:21:01 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Wed, 20 Sep 2006 08:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-85) Add support for base64
 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8427555.1158754861441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-85?page=all ]

Heiko Braun updated JBXB-85:
----------------------------

        Summary: Add support for base64 simple type bean properties to be XOP optimized  (was: Add support for base64 simple types to be XOP optimized)
    Description: 
Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:

<xs:element name="EchoBinaryAsString">
	<xs:complexType>
	<xs:sequence>
<xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
</xs:sequence>
</xs:complexType>
</xs:element>

The type xs:base64Binary needs be optimized by jbossxb.

  was:Currently this only works with complex types. In order to be interoperable with MSFT we need to support this.


> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Wed, 20 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1832) Improving JBoss
 WebConsole's snapshots
Message-ID: <7268833.1158758461838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1832?page=all ]

Darran Lofthouse updated JBAS-1832:
-----------------------------------

    Component/s: Web Console
                     (was: Management services)

> Improving JBoss WebConsole's snapshots
> --------------------------------------
>
>                 Key: JBAS-1832
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1832
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.0 Final
>         Environment: Not relevant
>            Reporter: Mathieu Bourrier
>            Priority: Minor
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The snapshots in the Webconsole cannot be started automatically on startup, as the Recording field isn't an attribute.
> 2 classes need to be modified, and the changes are quite small.
> Given topic describes changes to be made in order to manage it.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:02 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Wed, 20 Sep 2006 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-1832) Improving JBoss
 WebConsole's snapshots
Message-ID: <23925209.1158758462010.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1832?page=all ]

Darran Lofthouse reassigned JBAS-1832:
--------------------------------------

    Assignee: Darran Lofthouse

> Improving JBoss WebConsole's snapshots
> --------------------------------------
>
>                 Key: JBAS-1832
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1832
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.0 Final
>         Environment: Not relevant
>            Reporter: Mathieu Bourrier
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The snapshots in the Webconsole cannot be started automatically on startup, as the Recording field isn't an attribute.
> 2 classes need to be modified, and the changes are quite small.
> Given topic describes changes to be made in order to manage it.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:02 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Wed, 20 Sep 2006 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-148) Include
 Tomcat's
 SavedRequest object into the replication process in a Jboss-Tomcat
 clustered environment to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2076455.1158758462383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=comments#action_12343654 ] 
            
Alberto Rodriguez commented on JBCLUSTER-148:
---------------------------------------------

It's been pointed in Tomcat's developers list that section 7.7.2 (Distributed Environments) of JSR-154 (Servlet specfication) is said:

"Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine at a time"

This invalidates our approach unless that paragraph is changed in subsecuent revisions of the specfication ( this probably won't happen in the near future because of it's distributed VM shynchronization implications).



> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:02 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Wed, 20 Sep 2006 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCLUSTER-148) Include Tomcat's
 SavedRequest
 object into the replication process in a Jboss-Tomcat clustered environment
 to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6366477.1158758462641.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=all ]

Alberto Rodriguez closed JBCLUSTER-148.
---------------------------------------

    Resolution: Deferred

> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:23:01 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Wed, 20 Sep 2006 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-148) Include
 Tomcat's
 SavedRequest object into the replication process in a Jboss-Tomcat
 clustered environment to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30442773.1158758581252.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=comments#action_12343655 ] 
            
Alberto Rodriguez commented on JBCLUSTER-148:
---------------------------------------------

A copy of the interchanged messages can be read here:

http://marc.theaimsgroup.com/?l=tomcat-dev&m=115858715404605&w=2

> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:25:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Wed, 20 Sep 2006 09:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3675) Add LockOwnerName to
 ThreadDump output from ServerInfo
Message-ID: <25533160.1158758701199.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add LockOwnerName to ThreadDump output from ServerInfo
------------------------------------------------------

                 Key: JBAS-3675
                 URL: http://jira.jboss.com/jira/browse/JBAS-3675
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Darran Lofthouse
         Assigned To: Darran Lofthouse
             Fix For: JBossAS-4.0.6.CR1


The current thread dump shows what object a thread is waiting on but it does not show which thread currently owns the lock.

Add getLockOwnerName for each thread output.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:33:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30918891.1158759181364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Tom  Elrod updated JBREM-596:
-----------------------------

    Priority: Critical  (was: Major)

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:36:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-381) IIOP transport impl
	for remoting
Message-ID: <14843697.1158759361590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-381?page=all ]

Tom  Elrod updated JBREM-381:
-----------------------------

    Priority: Minor  (was: Critical)

> IIOP transport impl for remoting
> --------------------------------
>
>                 Key: JBREM-381
>                 URL: http://jira.jboss.com/jira/browse/JBREM-381
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1 final
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:36:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-562) publish performance
	benchmarks
In-Reply-To: <17974196.1154504171466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15027063.1158759361717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-562?page=all ]

Tom  Elrod closed JBREM-562.
----------------------------

    Resolution: Done

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972805#3972805

> publish performance benchmarks
> ------------------------------
>
>                 Key: JBREM-562
>                 URL: http://jira.jboss.com/jira/browse/JBREM-562
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: general
>    Affects Versions: 2.0.0.CR1 (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:36:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-47) Dynamic classloading
Message-ID: <31948240.1158759361231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-47?page=all ]

Tom  Elrod updated JBREM-47:
----------------------------

    Priority: Major  (was: Critical)

> Dynamic classloading
> --------------------
>
>                 Key: JBREM-47
>                 URL: http://jira.jboss.com/jira/browse/JBREM-47
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>          Components: general
>    Affects Versions: 1.0.1 beta
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> Need ability for dynamic classloading to satisfy two needs. The first, is when an ejb lookup is done, and if do not have the class on the client, can download the client classes for remoting. This is much more efficient than having to serialize all these classes (as there may be many and may not even know what they are until runtime). Also, would like to add the ability for client or server to pass implementation for interfaces across the wire and if the other side does not have those classes, can load them. Once particular case when this might be needed is if using JMX sub-system, client could create custom QueryExp? implementation and pass to the server, and the server could load that class and perform the query. Will require security around this.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:51:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 20 Sep 2006 09:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-308) DataModel
 instance changes
 even though the backing list did not when using PAGE scope
In-Reply-To: <29938082.1152829515513.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32960037.1158760261318.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-308?page=comments#action_12343661 ] 
            
Gavin King commented on JBSEAM-308:
-----------------------------------

Is it related to this forum thread: [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972892#3972892[/url]

> DataModel instance changes even though the backing list did not when using PAGE scope
> -------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-308
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-308
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>            Reporter: Chris Rudd
>
> The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected.
> When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. 
> The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. 
> I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection.
> I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ):
>  private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper)
>    {
>       
>       Context context = getDataModelContext(scope);
>       Object existingDataModel = context.get(name);
>       boolean dirty = existingDataModel == null || 
>             !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality
>       
>       if ( dirty )
>       {
>          if ( list != null )
>          {
>             context.set( name, wrapper.wrap(list) );
>          }
>          else
>          {
>             context.remove( name );
>          }
>       }
>       // If page scope, outject the existingDataModel even if there was no change
>       else if( scope==ScopeType.PAGE )
>       {
>          context.set( name, existingDataModel );
>       }
>       
>    }

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:19:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 10:19:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-145) Automate the
 trailblazer as part of QA
Message-ID: <6932816.1158761999738.JavaMail.jira@cloud.prod.atl2.jboss.com>

Automate the trailblazer as part of QA
--------------------------------------

                 Key: JBESB-145
                 URL: http://jira.jboss.com/jira/browse/JBESB-145
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Examples, Testing
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep 20 10:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 10:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-9) Remote the dom4j
 dependency from org.jboss.util.state.xml.StateMachineParser
Message-ID: <11341338.1158763621358.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remote the dom4j dependency from org.jboss.util.state.xml.StateMachineParser
----------------------------------------------------------------------------

                 Key: JBCOMMON-9
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-9
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: core
    Affects Versions: 1.0.0.CR1
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: 2.0.0.Beta, 1.0.0.GA


StateMachineParser is the only class in the common package that has a dependency on dom4j.

Re-write it so the dom4j dependency is removed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 10:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-9) Remove the dom4j
 dependency from org.jboss.util.state.xml.StateMachineParser
In-Reply-To: <11341338.1158763621358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13550077.1158763621502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-9?page=all ]

Dimitris Andreadis updated JBCOMMON-9:
--------------------------------------

    Summary: Remove the dom4j dependency from org.jboss.util.state.xml.StateMachineParser  (was: Remote the dom4j dependency from org.jboss.util.state.xml.StateMachineParser)

> Remove the dom4j dependency from org.jboss.util.state.xml.StateMachineParser
> ----------------------------------------------------------------------------
>
>                 Key: JBCOMMON-9
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-9
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.0.0.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: 2.0.0.Beta, 1.0.0.GA
>
>
> StateMachineParser is the only class in the common package that has a dependency on dom4j.
> Re-write it so the dom4j dependency is removed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 10:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3676) Upgrade jboss-common
	to 1.0.0.GA
Message-ID: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss-common to 1.0.0.GA
--------------------------------

                 Key: JBAS-3676
                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Wed Sep 20 10:57:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 10:57:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-84) The Xid
 implementation should
 implement the hashCode and equals methods from Object
Message-ID: <17429363.1158764279575.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-84?page=comments#action_12343665 ] 
            
Kevin Conner commented on JBTM-84:
----------------------------------

This issue has been fixed in revision 6317.


> The Xid implementation should implement the hashCode and equals methods from Object
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-84
>                 URL: http://jira.jboss.com/jira/browse/JBTM-84
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> XidImpl does not implement the equals and hashCode methods.  This prevents Xid being used in hash maps/sets.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:57:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 10:57:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-84) The Xid
 implementation should
 implement the hashCode and equals methods from Object
Message-ID: <31114480.1158764279713.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-84?page=all ]

Kevin Conner resolved JBTM-84.
------------------------------

    Fix Version/s: 4.2.2
       Resolution: Done

> The Xid implementation should implement the hashCode and equals methods from Object
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-84
>                 URL: http://jira.jboss.com/jira/browse/JBTM-84
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> XidImpl does not implement the equals and hashCode methods.  This prevents Xid being used in hash maps/sets.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:11:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-286) Weaken dependencies
 on unreleased MC 2.0
Message-ID: <13804037.1158765061202.JavaMail.jira@cloud.prod.atl2.jboss.com>

Weaken dependencies on unreleased MC 2.0
----------------------------------------

                 Key: JBAOP-286
                 URL: http://jira.jboss.com/jira/browse/JBAOP-286
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.0.0.alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:11:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-287) Tighten integration
 with MC 2.0 once it is released
Message-ID: <5859857.1158765061379.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tighten integration with MC 2.0 once it is released
---------------------------------------------------

                 Key: JBAOP-287
                 URL: http://jira.jboss.com/jira/browse/JBAOP-287
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.0.0.alpha2




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:17:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-124) atsintegration must
 have its own logging
Message-ID: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>

atsintegration must have its own logging
----------------------------------------

                 Key: JBTM-124
                 URL: http://jira.jboss.com/jira/browse/JBTM-124
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.2.1
         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:24:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-125) The transaction
 manager implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
Message-ID: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>

The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
--------------------------------------------------------------------------------------------------------------------------

                 Key: JBTM-125
                 URL: http://jira.jboss.com/jira/browse/JBTM-125
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-126) JTS XATerminator
 references arjunacore classes
Message-ID: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>

JTS XATerminator references arjunacore classes
----------------------------------------------

                 Key: JBTM-126
                 URL: http://jira.jboss.com/jira/browse/JBTM-126
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-126) JTS XATerminator
 references arjunacore classes
In-Reply-To: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17529656.1158766381466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-126?page=comments#action_12343666 ] 
            
Kevin Conner commented on JBTM-126:
-----------------------------------

Updates to the jts XATerminator were made in version 6318.

> JTS XATerminator references arjunacore classes
> ----------------------------------------------
>
>                 Key: JBTM-126
>                 URL: http://jira.jboss.com/jira/browse/JBTM-126
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-126) JTS XATerminator
 references arjunacore classes
In-Reply-To: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26535044.1158766381583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-126?page=all ]

Kevin Conner resolved JBTM-126.
-------------------------------

    Resolution: Done

> JTS XATerminator references arjunacore classes
> ----------------------------------------------
>
>                 Key: JBTM-126
>                 URL: http://jira.jboss.com/jira/browse/JBTM-126
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-124) atsintegration must
 have its own logging
In-Reply-To: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6688625.1158766381785.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-124?page=comments#action_12343667 ] 
            
Kevin Conner commented on JBTM-124:
-----------------------------------

Fixed in revision 6318.

> atsintegration must have its own logging
> ----------------------------------------
>
>                 Key: JBTM-124
>                 URL: http://jira.jboss.com/jira/browse/JBTM-124
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-124) atsintegration must
 have its own logging
In-Reply-To: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4961949.1158766381921.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-124?page=all ]

Kevin Conner resolved JBTM-124.
-------------------------------

    Resolution: Done

> atsintegration must have its own logging
> ----------------------------------------
>
>                 Key: JBTM-124
>                 URL: http://jira.jboss.com/jira/browse/JBTM-124
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 11:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-121) Check recovery
In-Reply-To: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11516905.1158766382309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-121?page=all ]

Mark Little updated JBTM-121:
-----------------------------

    Fix Version/s: 4.4
                       (was: 4.2.2)

> Check recovery
> --------------
>
>                 Key: JBTM-121
>                 URL: http://jira.jboss.com/jira/browse/JBTM-121
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:35:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:35:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-125) The transaction
 manager implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
In-Reply-To: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11545845.1158766559204.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-125?page=comments#action_12343668 ] 
            
Kevin Conner commented on JBTM-125:
-----------------------------------

Fixed in revision 6319.

> The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-125
>                 URL: http://jira.jboss.com/jira/browse/JBTM-125
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:35:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:35:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-125) The transaction
 manager implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
In-Reply-To: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7457325.1158766559376.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-125?page=all ]

Kevin Conner resolved JBTM-125.
-------------------------------

    Resolution: Done

> The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-125
>                 URL: http://jira.jboss.com/jira/browse/JBTM-125
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:38:00 2006
From: jira-events at jboss.com (Daniel Hannum (JIRA))
Date: Wed, 20 Sep 2006 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3258) JDBC artificats
 should throw SQLException when already closed
Message-ID: <7934716.1158766680316.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3258?page=comments#action_12343669 ] 
            
Daniel Hannum commented on JBAS-3258:
-------------------------------------

This temporary fix is not working for me. It won't compile because the two @Bind annotations are not allowed (duplicate annotation, it says). I've tried to adjust the pointcut to make it work with a single bind and it still throws the exceptions and still won't hit a breakpoint in the aspect.

How long until 4.0.4SP1 is out?

> JDBC artificats should throw SQLException when already closed
> -------------------------------------------------------------
>
>                 Key: JBAS-3258
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3258
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1
>
>
> In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL
> exception if the artifact is already closed. They should just return with an exception.
> From the Javadoc:
> "Calling the method close on a Statement  object that is already closed has no effect."
> e.g. In WrappedStatement
>    public void close() throws SQLException
>    {
>       synchronized (lock)
>       {
>          if (closed)
>             throw new SQLException("Already closed");
>          closed = true;
>       }
>       lc.unregisterStatement(this);
>       internalClose();
>    }
> this should be:
>    public void close() throws SQLException
>    {
>       synchronized (lock)
>       {
>          if (closed)
>             return;
>          closed = true;
>       }
>       lc.unregisterStatement(this);
>       internalClose();
>    }

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:39:59 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:39:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-287) Tighten
 integration with MC 2.0 once it is released
In-Reply-To: <5859857.1158765061379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30996014.1158766799759.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-287?page=comments#action_12343670 ] 
            
Kabir Khan commented on JBAOP-287:
----------------------------------

Remove the org.jboss.aop.annotation.factory.duplicate package and make use the org.jboss.annotation.factory classes from container
Reintroduce the MetaDataContext into the org.jboss.aop.proxy.container classes (This has currently been "de-typed")
Change build script to include the container in the library.classpath so it is available both when compiling and when running the tests
Index: C:/cygwin/home/Kabir/sourcecontrol/jboss-head/aop/build.xml
===================================================================
--- C:/cygwin/home/Kabir/sourcecontrol/jboss-head/aop/build.xml	(revision 57004)
+++ C:/cygwin/home/Kabir/sourcecontrol/jboss-head/aop/build.xml	(working copy)
@@ -86,7 +86,7 @@
          <path refid="oswego.concurrent.classpath"/>
          <path refid="junit.junit.classpath"/>
          <path refid="jboss.profiler.jvmti.classpath"/>
-         <path refid="jboss.microcontainer.classpath"/>
+         <!--<path refid="jboss.microcontainer.classpath"/>-->
       </path>
 
       <!-- Defines jrockit.home -->
@@ -150,6 +150,7 @@
 
       <!-- The classpath required to build classes. -->
       <path id="javac.classpath">
+         <path refid="jboss.microcontainer.classpath"/>
          <pathelement path="${classpath}"/>
          <pathelement path="${local.classpath}"/>
          <path refid="thirdparty.classpath"/>
@@ -259,6 +260,8 @@
          <src path="${source.java}"/>
          <exclude name="org/jboss/aop/definition/**"/>
          <exclude name="org/jboss/aop/hook/JRockit*"/>
+<exclude name="**/ClassInfoMethodHashing.java"/>
+
          <classpath refid="javac.classpath"/>
       </javac>
    </target>
@@ -615,6 +618,7 @@
          <include name="**/*.java"/>
          <exclude name="org/jboss/test/aop/jdk15*/**/*.java"/>
          <exclude name="org/jboss/test/aop/memoryleaks/**/*.java"/>
+         <exclude name="**/methodhashing/*"/>
       </javac>
    </target>
 



> Tighten integration with MC 2.0 once it is released
> ---------------------------------------------------
>
>                 Key: JBAOP-287
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-287
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:45:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25429330.1158767101375.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343671 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

After updating libraries ClientCrashTwoConnectionsTest  is passing without any failures. So, the fix is perfect for messaging.

We will need a tagged snapshot or a minor release for messaging now.

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:48:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <29393582.1158767281233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-87?page=all ]

Kevin Conner reassigned JBTM-87:
--------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:51:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <16575748.1158767461222.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-87?page=comments#action_12343672 ] 
            
Kevin Conner commented on JBTM-87:
----------------------------------

The LastResourceCommitOptimisation for JTA and JTS must be put back into the code base.  In addition we must support the org.jboss.tm.LastResource interface

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:53:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:53:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
Message-ID: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>

UID must befine a value for the maximum UID and enforce the ordering during comparison.
---------------------------------------------------------------------------------------

                 Key: JBTM-127
                 URL: http://jira.jboss.com/jira/browse/JBTM-127
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.

UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:56:00 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
In-Reply-To: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1537065.1158767760898.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-127?page=comments#action_12343673 ] 
            
Kevin Conner commented on JBTM-127:
-----------------------------------

Fixed in revision 6324.

> UID must befine a value for the maximum UID and enforce the ordering during comparison.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBTM-127
>                 URL: http://jira.jboss.com/jira/browse/JBTM-127
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.
> UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:56:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
In-Reply-To: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14133865.1158767761025.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-127?page=all ]

Kevin Conner resolved JBTM-127.
-------------------------------

    Resolution: Done

> UID must befine a value for the maximum UID and enforce the ordering during comparison.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBTM-127
>                 URL: http://jira.jboss.com/jira/browse/JBTM-127
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.
> UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:58:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 20 Sep 2006 11:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-711) During
 undeployment stop is being called twice
Message-ID: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>

During undeployment stop is being called twice 
-----------------------------------------------

                 Key: EJBTHREE-711
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
             Fix For: EJB 3.0 RC9 - FD


After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:58:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <7262689.1158767881261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment: jboss-aop.jar
                jboss-aop-jdk50.jar

These files contain what will be in JBoss AOP 2.0.0.alpha1

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>         Attachments: jboss-aop-jdk50.jar, jboss-aop.jar
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 12:15:01 2006
From: jira-events at jboss.com (Phillip Thurmond (JIRA))
Date: Wed, 20 Sep 2006 12:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
Message-ID: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
------------------------------------------------------------------------------------------

                 Key: JBAS-3678
                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Sparc Solaris 10
jdk 1.4.2_08
            Reporter: Phillip Thurmond


org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10

Testcase: testMyService took 1.656 sec
        Caused an ERROR
null
java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:141)
        at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
1)
        at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
        at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
14)
        at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
137)
        at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
ava:58)
        at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
        at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
        at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
viceClientTestCase.java:70)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
s-bmp
        at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
        at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
        at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
java:77)
        at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
:63)
        ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 12:37:58 2006
From: jira-events at jboss.com (Phillip Thurmond (JIRA))
Date: Wed, 20 Sep 2006 12:37:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23612586.1158770278875.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3678?page=comments#action_12343676 ] 
            
Phillip Thurmond commented on JBAS-3678:
----------------------------------------

I have tried running this test with DISPLAY correctly set and also with -Djava.awt.headless=true.  Test still fails.



> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:02:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-600)
 org.jboss.test.remoting.lease.multiplex.MultiplexLeaseTestCase fails
Message-ID: <23571178.1158778921092.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.test.remoting.lease.multiplex.MultiplexLeaseTestCase fails
--------------------------------------------------------------------

                 Key: JBREM-600
                 URL: http://jira.jboss.com/jira/browse/JBREM-600
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport-multiplex
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Ron Sigal
             Fix For: 2.2.0.Beta1 (Bluto)


When run org.jboss.test.remoting.lease.multiplex.MultiplexLeaseTestCase, the test fails.  From debugging, the ServerInvoker's leaseManagement variable is not set to true when it's invoke() method is called (thus by-passing leasing).  

Also noticed when debugging that when Connector.addConnectionListener() calls:

invoker.addConnectionListener(listener);

that the invoker instance was MultiplexServerInvoker[master] (this is where the leaseManagement variable gets set to true) and when the PING invocation request is processed within ServerInvoker.invoke() method (where checks to see if leaseManagement variable is true and is not), the invoker instance is MultiplexServerInvoker[virtual:/127.0.0.1:5400->/127.0.0.1:1914].

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:04:57 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Wed, 20 Sep 2006 15:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-31) Migration to
	Portal 2.4
Message-ID: <13309733.1158779098003.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-31?page=all ]

Ryszard Kozmik resolved JBFORUMS-31.
------------------------------------

    Resolution: Done

> Migration to Portal 2.4
> -----------------------
>
>                 Key: JBFORUMS-31
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-31
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 1 day, 6 hours, 10 minutes
>
> Because of that JBForums have many dependencies on JBPortal and it is still changing there is a need to keep up to those changes.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:43:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 15:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10390499.1158781381280.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Tom  Elrod resolved JBREM-596.
------------------------------

    Resolution: Done

Repository binary - http://repository.jboss.com/jboss/remoting/2.2.0.Alpha1/lib/
CVS tag - remoting_2_2_0_Alpha1

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:50:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 15:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18582110.1158781801143.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic closed JBREM-596.
---------------------------------


> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:06:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20167188.1158782761756.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=comments#action_12343685 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-505:
---------------------------------------------

Also, the same solution was applied to FirstReceiverPointToPointRouter, so if reverted, needs to be reverted on both classes.

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:09:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32170578.1158782941657.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov updated JBMESSAGING-546:
----------------------------------------

    Comment: was deleted

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:11:59 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 16:11:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17898048.1158783119957.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=all ]

Clebert Suconic updated JBMESSAGING-528:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89208  (was: http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967042)

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:13:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:13:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14589605.1158783238630.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343688 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

The main thread grabs ServerConsumerEndpoint's main lock in ServerConsumerEndpoint.close() and tries to remove itself from the channel's router. Cannot do that because Thread-3 holds the router's lock.
Thread-3 delivers a new reference to ServerConsumerEndpoint while holding the router's lock (unnecessarily), and tries to grab ServerConsumerEndpoint's main lock, which is unavailable.

The deadlock was fixed by reducing the time Thread-3 holds the router's lock. 

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:16:00 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11707669.1158783360701.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov closed JBMESSAGING-546.
---------------------------------------

    Resolution: Done

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:24:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 16:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
In-Reply-To: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <580584.1158783841071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-540?page=all ]

Clebert Suconic closed JBMESSAGING-540.
---------------------------------------

    Fix Version/s:     (was: 1.2.1)
       Resolution: Won't Fix

Having the integration test on JBoss AS is the right way to do this task.

We already have a JIRA issue for integration tasks.

> A testsuite testing client and server on different IPs
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-540
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>
> The current testsuite tests both client and server on the same network. 
> We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:34:00 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 20 Sep 2006 16:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-356) Session bean
	assertions
Message-ID: <26202711.1158784440217.JavaMail.jira@cloud.prod.atl2.jboss.com>

Session bean assertions
-----------------------

                 Key: JBSEAM-356
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-356
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King


For people who like more of a design-by-contract style, we could let you specify Hibernate Validator annotations on the session bean, and check them after @PostConstruct and before and after each business method.

eg.

@Stateful
public class Foo {
    @NotNull private Bar bar;
    @Min(0) int count;
}

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:47:00 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 20 Sep 2006 16:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-682) create test for
	JBossTS
In-Reply-To: <954187.1154728331873.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5522463.1158785220493.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-682?page=all ]

William DeCoste closed EJBTHREE-682.
------------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
       Resolution: Done

> create test for JBossTS
> -----------------------
>
>                 Key: EJBTHREE-682
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-682
>             Project: EJB 3.0
>          Issue Type: Task
>            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

        


From jira-events at jboss.com  Wed Sep 20 16:59:01 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 20 Sep 2006 16:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1046) documentation
 for Ldap/Portal integration
In-Reply-To: <28666807.1158567770641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22563430.1158785941325.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1046?page=comments#action_12343694 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1046:
-----------------------------------------------

Documentation should provide the chart/matrix with the level of support for
1/ authentication &roles
2/ profile integration
3/ role assignment

in

1/ DB implementation
2/ Simple LDAP implementation
3/ Complex LDAP implementation

> documentation for Ldap/Portal integration
> -----------------------------------------
>
>                 Key: JBPORTAL-1046
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1046
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Documentation
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>
> Create documentation of configuring Portal with LDAP. It needs to cover new implementation of identity modules in 2.6

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 17:31:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 17:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-548) Remote tests
 occasionaly fail with "Cannot find generator for serverid:server.0"
Message-ID: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remote tests occasionaly fail with "Cannot find generator for serverid:server.0"
--------------------------------------------------------------------------------

                 Key: JBMESSAGING-548
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Minor
             Fix For: 1.0.1.CR5


Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:13:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 20 Sep 2006 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1051) NPE if no
 session information exists when trying to update the user cookies
Message-ID: <22189599.1158790381710.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE if no session information exists when trying to update the user cookies
---------------------------------------------------------------------------

                 Key: JBPORTAL-1051
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1051
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:23:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 18:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1618819.1158791037937.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=comments#action_12343703 ] 
            
Clebert Suconic commented on JBMESSAGING-528:
---------------------------------------------

I'm updating documentation on head.

We will need to upload docs on jboss.org as soon as we get the release out.

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:30:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 18:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29863675.1158791401322.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=all ]

Clebert Suconic closed JBMESSAGING-528.
---------------------------------------

    Resolution: Done

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:40:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 18:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9762962.1158792057428.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=comments#action_12343706 ] 
            
Clebert Suconic commented on JBMESSAGING-528:
---------------------------------------------

Documentation also updated on Branch_1_0

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:49:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <22904332.1158792541686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov updated JBMESSAGING-361:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:49:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <30666056.1158792541863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Ovidiu Feodorov updated JBMESSAGING-431:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ron Sigal)

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:49:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 20 Sep 2006 18:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1051) NPE if no
 session information exists when trying to update the user cookies
In-Reply-To: <22189599.1158790381710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4061831.1158792541946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1051?page=all ]

Chris Laprun resolved JBPORTAL-1051.
------------------------------------

    Resolution: Done

> NPE if no session information exists when trying to update the user cookies
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1051
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1051
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:55:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:55:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <30630088.1158792958925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov updated JBMESSAGING-361:
----------------------------------------

    Assignee: Ovidiu Feodorov  (was: Clebert Suconic)

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:55:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:55:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <6308726.1158792959053.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov closed JBMESSAGING-361.
---------------------------------------

    Resolution: Done

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:57:58 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 20 Sep 2006 18:57:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11172959.1158793078445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3678?page=all ]

Ryan Campbell reassigned JBAS-3678:
-----------------------------------

    Assignee: Jason T. Greene

Jason,

Can you look at this?  We need this for a solaris certification for JBoss 4.0.4.  We believe it may be a bad test, but would like to have a second opinion.

Thanks,
Ryan

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Jason T. Greene
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:57:58 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 20 Sep 2006 18:57:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30090953.1158793078602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3678?page=all ]

Ryan Campbell updated JBAS-3678:
--------------------------------

    Comment: was deleted

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Jason T. Greene
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:35:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 19:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-548) Remote tests
 occasionaly fail with "Cannot find generator for serverid:server.0"
In-Reply-To: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22359041.1158795357382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-548?page=comments#action_12343711 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-548:
---------------------------------------------

The testsuite passes consistently if I comment out the JBossConnection.finalizer(), so until more research is done in that direction, it'll stay commented out.

> Remote tests occasionaly fail with "Cannot find generator for serverid:server.0"
> --------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-548
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:35:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 19:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-548)
 JBossConnection.finalizer()
 causes remote tests to occasionaly fail with "Cannot find generator for
 serverid:server.0"
In-Reply-To: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3495639.1158795357500.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-548?page=all ]

Ovidiu Feodorov updated JBMESSAGING-548:
----------------------------------------

          Summary: JBossConnection.finalizer() causes remote tests to occasionaly fail with "Cannot find generator for serverid:server.0"  (was: Remote tests occasionaly fail with "Cannot find generator for serverid:server.0")
    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)

> JBossConnection.finalizer() causes remote tests to occasionaly fail with "Cannot find generator for serverid:server.0"
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-548
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:43:58 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 19:43:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <27706349.1158795838355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Clebert Suconic closed JBMESSAGING-431.
---------------------------------------

    Resolution: Done

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:49:57 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Wed, 20 Sep 2006 19:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-186) Write a blog entry
 about the beta release
Message-ID: <5928402.1158796197448.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-186?page=all ]

Alejandro Guizar resolved BPEL-186.
-----------------------------------

    Resolution: Done

> Write a blog entry about the beta release
> -----------------------------------------
>
>                 Key: BPEL-186
>                 URL: http://jira.jboss.com/jira/browse/BPEL-186
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:10:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-547) Upgrade
 JBossSerialization to 1.0.3.GA
In-Reply-To: <24696517.1158689157470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19544870.1158797456914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-547?page=all ]

Ovidiu Feodorov updated JBMESSAGING-547:
----------------------------------------

    Priority: Minor  (was: Major)

> Upgrade JBossSerialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBMESSAGING-547
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> I will do it as soon as the release is out.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:14:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-287)
 RemotingTest.testConnectionListener() invalid
Message-ID: <23539326.1158797697917.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ]

Ovidiu Feodorov updated JBMESSAGING-287:
----------------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.0.1.CR5)

> RemotingTest.testConnectionListener() invalid
> ---------------------------------------------
>
>                 Key: JBMESSAGING-287
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. 
> After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:14:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:14:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16538182.1158797698104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Ovidiu Feodorov closed JBMESSAGING-541.
---------------------------------------

    Resolution: Done

fixed with Remoting 2.2.0.Alpha1

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Wed Sep 20 20:26:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:26:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-526)
 JMSRedelivered flag not
 correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28212709.1158798415592.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-526:
-------------------------------------------

    Assignee: Ovidiu Feodorov  (was: Clebert Suconic)

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:26:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29579019.1158798416220.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-545:
-------------------------------------------

    Assignee: Ovidiu Feodorov

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:48:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-549) Remoting
 2.2.0.Alpha1 breaks 2 crash tests
Message-ID: <11678719.1158799736606.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remoting 2.2.0.Alpha1 breaks 2 crash tests
------------------------------------------

                 Key: JBMESSAGING-549
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Clebert Suconic
            Priority: Blocker
             Fix For: 1.0.1.CR5


1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest

Error setting up client lease upon performing connect.

javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
	at sun.rmi.transport.Transport$1.run(Transport.java:148)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
	at java.lang.Thread.run(Thread.java:534)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
	at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115)


2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest

Error setting up client lease upon performing connect.

javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
	at sun.rmi.transport.Transport$1.run(Transport.java:148)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
	at java.lang.Thread.run(Thread.java:534)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
	at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115)


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 23:30:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 23:30:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-550) Add JBoss
 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
Message-ID: <5205854.1158809458341.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add JBoss 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
------------------------------------------------------------------------------

                 Key: JBMESSAGING-550
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-550
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Minor




-- 
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

        


From MAILER-DAEMON at lists.jboss.org  Wed Sep 20 23:38:11 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Wed, 20 Sep 2006 23:38:11 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609210338.k8L3cBhd007834@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From MAILER-DAEMON at lists.jboss.org  Wed Sep 20 23:38:26 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Wed, 20 Sep 2006 23:38:26 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609210338.k8L3cQ72007849@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From jira-events at jboss.com  Thu Sep 21 00:17:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 00:17:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-289) Make service
 container configurable wrt datasource and persistence manager config
Message-ID: <610384.1158812278729.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-289?page=all ]

Ovidiu Feodorov updated JBMESSAGING-289:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)

This fix is useful mostly for clustering testing, so I'll do it while working for the Alpha release.

> Make service container configurable wrt datasource and persistence manager config
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-289
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-289
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>
> Must be made configurable so test suite can be run against different databases with different pm configs

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 00:25:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 00:25:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <28491757.1158812759047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Priority: Blocker  (was: Critical)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 00:41:57 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Thu, 21 Sep 2006 00:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-601) Integrate http with
	messaging
Message-ID: <14467485.1158813717043.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate http with messaging
-----------------------------

                 Key: JBREM-601
                 URL: http://jira.jboss.com/jira/browse/JBREM-601
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.Beta1 (Bluto)
            Reporter: Ron Sigal
         Assigned To: Tom  Elrod
             Fix For: 2.2.0.Beta1 (Bluto)


A few changes need to be made for the http transport to work with JBossMessaging.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 00:48:55 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 00:48:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3634) Acknowledgement of
 transacted message in MessageListener should be inside delivery lock
In-Reply-To: <4660406.1157632723860.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5136684.1158814135967.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3634?page=all ]

Adrian Brock updated JBAS-3634:
-------------------------------

    Description: 
The acknowledgement of a transacted message for a MessageListener
should be inside the delivery lock.

Otherwise the addition of the acknowledgement could be competing with other
operations on the session, e.g. commit/rollback/recover.


  was:
The acknowledgement of a transacted message for a MessageListener
should be inside the delivery lock.

Otherwise the addition of the acknowledgement could be competing with other
operations on the session, e.g. commit/rollback/recover.

org.jboss.mq.SpyMessageConsumer::run()

+            // Try to obtain the session delivery lock
+           // This avoids concurrent delivery to message listeners in the same session as per spec
+            boolean gotDeliveryLock = false;
+            while (gotDeliveryLock == false)
+            {

            if (session.transacted)
            {
               // REVIEW: for an XASession without a transaction this will ack the message
               // before it has been processed. Plain message listeners
               // are not supported in a j2ee environment, but what if somebody is trying 
               // to be clever?
               if (trace)
                  log.trace("run() acknowledging message in tx mes=" + mes.getJMSMessageID() + " " + this); 
               session.connection.spyXAResourceManager.ackMessage(session.getCurrentTransactionId(), mes);
            }

-            // Try to obtain the session delivery lock
-            // This avoids concurrent delivery to message listeners in the same session as per spec
-            boolean gotDeliveryLock = false;
-            while (gotDeliveryLock == false)
-            {


> Acknowledgement of transacted message in MessageListener should be inside delivery lock
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-3634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3634
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> The acknowledgement of a transacted message for a MessageListener
> should be inside the delivery lock.
> Otherwise the addition of the acknowledgement could be competing with other
> operations on the session, e.g. commit/rollback/recover.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:04:57 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3634) Acknowledgement of
 transacted message in MessageListener should be inside delivery lock
In-Reply-To: <4660406.1157632723860.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18791645.1158815097600.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3634?page=all ]

Adrian Brock closed JBAS-3634.
------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

> Acknowledgement of transacted message in MessageListener should be inside delivery lock
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-3634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3634
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> The acknowledgement of a transacted message for a MessageListener
> should be inside the delivery lock.
> Otherwise the addition of the acknowledgement could be competing with other
> operations on the session, e.g. commit/rollback/recover.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:06:56 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19272419.1158815216105.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Adrian Brock closed JBAS-3628.
------------------------------

    Resolution: Done

> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Thu Sep 21 01:08:58 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3468) JMS Connection starts
 ping thread
 before ClientID is set resulting in the ClientMonitorInterceptor to close
 the connection after client timeout
In-Reply-To: <11361240.1154691131936.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31810537.1158815338412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]

Adrian Brock closed JBAS-3468.
------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

> JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3468
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3468
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP
>            Reporter: Francis Labaere
>         Assigned To: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection  is set (explicitely using setClientID or implicitely).   The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
> The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap.  When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one.  When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken.  Subsequent calls to the server will generate exceptions: User session is not valid.
> On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
> Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive: 
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
> 2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.'  This exception is being propogated to the client as a HTTPILResponse.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade at 2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade at 1343c2a)
> On the Client side: following stacktrace is visible
> 13:17:57 [MessageListenerThread - MyTopic] WARN  org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> mq.Connection should start the ping thread after the ClientID is known.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:10:57 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
In-Reply-To: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3156181.1158815457165.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3620?page=all ]

Adrian Brock closed JBAS-3620.
------------------------------

    Resolution: Done

> JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBossMQ's PersistenceManager has a mechanism to retry recovery
> a number of times "RecoveryRetries".
> However, this only applies to the data recovery. If it fails 
> (e.g. due to database or network glitch)
> while checking/creating the database schema
> then no retries are done.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:10:57 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3627) Write test to test
 rollback of a NACK in 2PC
In-Reply-To: <22340756.1157539649297.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12187319.1158815457365.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3627?page=all ]

Adrian Brock closed JBAS-3627.
------------------------------

    Resolution: Done

> Write test to test rollback of a NACK in 2PC
> --------------------------------------------
>
>                 Key: JBAS-3627
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3627
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to test BasicQueue.acknowledge()
> whether it should also add a PostRollback task for a NACK under a transaction.
> i.e. 
>       // Was it a negative acknowledge??
>       if (!item.isAck)
>       {
>          Runnable task = new RestoreMessageTask(m);
>          server.getPersistenceManager().getTxManager().addPostCommitTask(txId, task);
> +         server.getPersistenceManager().getTxManager().addPostRollbackjTask(txId, task);
>       }
> The  hard part is wrting such a test since it is a normal condition.
> Probably need to use direct invocation on the server invoker ?

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 02:22:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 02:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3117058.1158819721237.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Ovidiu Feodorov updated JBMESSAGING-545:
----------------------------------------

    Priority: Blocker  (was: Major)

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 02:34:01 2006
From: jira-events at jboss.com (Onno de Groote (JIRA))
Date: Thu, 21 Sep 2006 02:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3679) BMP entitybeans cause
 db-deadlocks
Message-ID: <29336818.1158820441651.JavaMail.jira@cloud.prod.atl2.jboss.com>

BMP entitybeans cause db-deadlocks
----------------------------------

                 Key: JBAS-3679
                 URL: http://jira.jboss.com/jira/browse/JBAS-3679
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Transaction Manager
    Affects Versions: JBossAS-3.2.7 Final
         Environment: windows 2003, sun jvm 1.4.2_06, INet Opta JDBC driver 6.04, SQLSERVER 2000
            Reporter: Onno de Groote
         Assigned To: Adrian Brock


when using local-tx datasources with no transactionisolation-level specified, it looks like jboss sets it to repeatable-read or higher. The problem with this situation is that in high concurrency situations, two threads using the same entity-bean ( with or without same primary-key ) cause deadlocks in SQLServer. The reason for this is that de select queries in the findby and ejbload code set S-locks on the indexes in the database, thereby blocking any update query of a different thread. In the situation that thread-1 first performs the findby and ejbload, causing S-locks, after which thread-2 does the same, after which thread-1 tries ejbstore, which blocks because of the S-locks of thread-2. Then thread-2 tries the ejbstore, which in turn is blocked by the S-locks of thread-1. SQLServer detectes a deadlock and selects a deadlock victim and one transaction fails. In this case there should not have been a problem so the transaction-failure is incorrect and only caused by the wrong transactionisolation level

-- 
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

       



From jira-events at jboss.com  Thu Sep 21 02:48:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 02:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-655) Refactor
	@Service beans
In-Reply-To: <30703765.1153251191416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <231379.1158821281612.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-655?page=all ]

Carlo de Wolf resolved EJBTHREE-655.
------------------------------------

    Resolution: Rejected

> Refactor @Service beans
> -----------------------
>
>                 Key: EJBTHREE-655
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-655
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Refactor @Service beans to fix a number of problems:
> * magic methods for lifecycle methods:
>   - create/start/stop/destroy
> * lifecycle methods are not required to be in @Management (MBean) interface.
> * @Management interface is not registered with the ServiceController (Controller in MC land).  It *IS* registered as a regular MBean though.
> * If lifecycle methods exist on @Management interface, they must be intercepted on the container so that the appropriate Controler start/stop is done on the container.  This would mean that you have to specify a <bind> in the Service aspect domain in ejb3-interceptors-aop.xml

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 03:04:01 2006
From: jira-events at jboss.com (warren crossing (JIRA))
Date: Thu, 21 Sep 2006 03:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3680) URLDeployer deploys
 before JAR/WAR/EAR available
Message-ID: <8020433.1158822241606.JavaMail.jira@cloud.prod.atl2.jboss.com>

URLDeployer deploys before JAR/WAR/EAR available
------------------------------------------------

                 Key: JBAS-3680
                 URL: http://jira.jboss.com/jira/browse/JBAS-3680
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Installer
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Linux SCP
            Reporter: warren crossing
         Assigned To: Alex Pinkin


I scp my war into the deployment directory

and I get spewage below.

you must scan the lastmodified to see if it has changed 

if is has changed you must add additional logic..

sleep for 1/2 a second and then check lastmodified again 

that means wait until file is complete!

org.jboss.deployment.DeploymentException: invalid distance code; - nested throwable: (java.util.zip.ZipException: invalid distance code)
        at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.java:374)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.deployment.SubDeployerInterceptorSupport.init(SubDeployerInterceptorSupport.java:119)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.init(SubDeployerInterceptorSupport.java:172)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:87)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy42.init(Unknown Source)
        at org.jboss.deployment.MainDeployer.init(MainDeployer.java:861)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:798)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
        at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy6.deploy(Unknown Source)
        at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
        at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: java.util.zip.ZipException: invalid distance code
        at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
        at java.util.zip.ZipInputStream.read(ZipInputStream.java:139)
        at java.util.jar.JarInputStream.read(JarInputStream.java:171)
        at org.jboss.util.file.JarUtils.unjar(JarUtils.java:300)
        at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.j

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 03:32:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 03:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24003876.1158823921337.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=all ]

Carlo de Wolf updated EJBTHREE-711:
-----------------------------------

        Fix Version/s: EJB 3.0 RC10 - FD
                           (was: EJB 3.0 RC9 - FD)
    Affects Version/s: EJB 3.0 RC9 - FD

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 03:34:01 2006
From: jira-events at jboss.com (Jason T. Greene (JIRA))
Date: Thu, 21 Sep 2006 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25570373.1158824041387.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3678?page=comments#action_12343723 ] 
            
Jason T. Greene commented on JBAS-3678:
---------------------------------------

Yes, I remember this problem. The issue was that the testsuite has a
replacefilter that was applying to everything in resources/webservices,
including binary files. On windows this isn't a problem, but on Unix it
is because of the CRLF -> LF conversion, which corrupts the image file
that is used by this test. The solution is to make the replacefilter
only apply to text files (*.xml, *.wsdl, etc). 

-Jason

JBoss
second
org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
------------------------------------------------------------------------
org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHand
le
org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartI
mp
org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBind
in
org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBin
di
org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP1
1B
org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.t
es
java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:6
4)
org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageD
at
org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataC
on
administrators:
http://www.atlassian.com/software/jira


> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Jason T. Greene
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 04:14:01 2006
From: jira-events at jboss.com (jarkko Lietolahti (JIRA))
Date: Thu, 21 Sep 2006 04:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-357) Add support in Seam
 for intra portlet communication.
Message-ID: <24475927.1158826441399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support in Seam for intra portlet communication. 
-----------------------------------------------------

                 Key: JBSEAM-357
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-357
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: jarkko Lietolahti
            Priority: Critical


When using Seam in Portal environment make it possible to specify which PortletSession context is used to storage attributes. See forum thread for more information.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 04:26:01 2006
From: jira-events at jboss.com (Thomas Heute (JIRA))
Date: Thu, 21 Sep 2006 04:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12496251.1158827161454.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Thomas Heute resolved JBPORTAL-998.
-----------------------------------

    Resolution: Done

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse-2.6.patch, eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 04:26:01 2006
From: jira-events at jboss.com (Thomas Heute (JIRA))
Date: Thu, 21 Sep 2006 04:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19162236.1158827161648.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Thomas Heute updated JBPORTAL-998:
----------------------------------

    Fix Version/s: 2.4.1 Final
                   2.6.Alpha1

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: eclipse-2.6.patch, eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 05:56:04 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Thu, 21 Sep 2006 05:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3674) service
 MetricsLookup dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1853858.1158832564140.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3674?page=comments#action_12343725 ] 
            
abo abo commented on JBAS-3674:
-------------------------------

can you please be a little more specific?

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 05:56:04 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 05:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3680) URLDeployer deploys
 before JAR/WAR/EAR available
In-Reply-To: <8020433.1158822241606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2129885.1158832564661.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3680?page=all ]

Dimitris Andreadis closed JBAS-3680.
------------------------------------

    Resolution: Rejected

You need to move the file in the deploy directory atomically, e.g. copy/ftp to a different location in the same filesystem (long operation), then do a move (mv) which is an atomic operation.

> URLDeployer deploys before JAR/WAR/EAR available
> ------------------------------------------------
>
>                 Key: JBAS-3680
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3680
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Linux SCP
>            Reporter: warren crossing
>         Assigned To: Alex Pinkin
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I scp my war into the deployment directory
> and I get spewage below.
> you must scan the lastmodified to see if it has changed 
> if is has changed you must add additional logic..
> sleep for 1/2 a second and then check lastmodified again 
> that means wait until file is complete!
> org.jboss.deployment.DeploymentException: invalid distance code; - nested throwable: (java.util.zip.ZipException: invalid distance code)
>         at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.java:374)
>         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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>         at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
>         at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
>         at org.jboss.deployment.SubDeployerInterceptorSupport.init(SubDeployerInterceptorSupport.java:119)
>         at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.init(SubDeployerInterceptorSupport.java:172)
>         at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:87)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>         at $Proxy42.init(Unknown Source)
>         at org.jboss.deployment.MainDeployer.init(MainDeployer.java:861)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:798)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>         at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>         at $Proxy6.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
> Caused by: java.util.zip.ZipException: invalid distance code
>         at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
>         at java.util.zip.ZipInputStream.read(ZipInputStream.java:139)
>         at java.util.jar.JarInputStream.read(JarInputStream.java:171)
>         at org.jboss.util.file.JarUtils.unjar(JarUtils.java:300)
>         at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.j

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 06:14:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 06:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10242062.1158833641642.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=comments#action_12343727 ] 
            
Carlo de Wolf commented on EJBTHREE-711:
----------------------------------------

First stop:
12:09:01,055 INFO  [ServiceContainer] stop called
java.lang.Exception: STACKTRACE
        at org.jboss.ejb3.service.ServiceContainer.stop(ServiceContainer.java:172)
        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.jboss.ejb3.ServiceDelegateWrapper.stopService(ServiceDelegateWrapper.java:118)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
        at $Proxy0.stop(Unknown Source)
        at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56)
        at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
        at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
        at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
        at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
        at org.jboss.system.ServiceController.doChange(ServiceController.java:633)
        at org.jboss.system.ServiceController.stop(ServiceController.java:457)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy91.stop(Unknown Source)
        at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:151)
        at org.jboss.ejb3.JmxKernelAbstraction.uninstall(JmxKernelAbstraction.java:178)
        at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:501)
        at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
        at $Proxy0.stop(Unknown Source)
        at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56)
        at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
        at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
        at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
        at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
        at org.jboss.system.ServiceController.doChange(ServiceController.java:633)
        at org.jboss.system.ServiceController.stop(ServiceController.java:457)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy29.stop(Unknown Source)
        at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:469)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.ws.integration.jboss.DeployerInterceptor.stop(DeployerInterceptor.java:122)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy30.stop(Unknown Source)
        at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417)
        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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)


> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 06:14:02 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Thu, 21 Sep 2006 06:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3681) EJB3.0 Session bean
	lookup
Message-ID: <5574956.1158833642890.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3.0 Session bean lookup
--------------------------

                 Key: JBAS-3681
                 URL: http://jira.jboss.com/jira/browse/JBAS-3681
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.CR2
         Environment: JBoss4.0.4CR2
            Reporter: madan srinivas
         Assigned To: Bill Burke


I get ejb not bound exception when i look up session bean

sessoin bean jndi name is mentioned using annotation in hte code as 

@Stateless
@RemoteBinding(jndiBinding="ejb/remote/FileDetails")

the look up code is 

Properties env = new java.util.Properties();		
		
env.setProperty("java.naming.provider.url", "http://localhost:8080/invoker/JNDIFactory");
env.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
env.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
		
InitialContext ctx = new InitialContext(env);
FileDetailsClientBean filesession =  (FileDetailsClientBean)ctx.lookup("ejb/remote/FileDetails");		
filesession.addFileDetails();

Pls help me resolve this and let me know if the code is correct

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 06:14:03 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 06:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24368268.1158833643068.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=comments#action_12343728 ] 
            
Carlo de Wolf commented on EJBTHREE-711:
----------------------------------------

Second stop:
12:09:01,086 INFO  [ServiceContainer] stop called
java.lang.Exception: STACKTRACE
        at org.jboss.ejb3.service.ServiceContainer.stop(ServiceContainer.java:172)
        at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:504)
        at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
        at $Proxy0.stop(Unknown Source)
        at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56)
        at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
        at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
        at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
        at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
        at org.jboss.system.ServiceController.doChange(ServiceController.java:633)
        at org.jboss.system.ServiceController.stop(ServiceController.java:457)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy29.stop(Unknown Source)
        at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:469)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.ws.integration.jboss.DeployerInterceptor.stop(DeployerInterceptor.java:122)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy30.stop(Unknown Source)
        at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417)
        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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)


> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 07:02:03 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 07:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11640286.1158836523613.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=comments#action_12343729 ] 
            
Carlo de Wolf commented on EJBTHREE-711:
----------------------------------------

The container is stopped at Ejb3Deployment.java:501 and Ejb3Deployment:504.

It appears that container.stop() is redundant.

Note that Ejb3Deployer.startService & Ejb3Deployer.stopService are very asymetrical. Is this by design?

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 08:01:00 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 08:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-286) Weaken dependencies
 on unreleased MC 2.0
In-Reply-To: <13804037.1158765061202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4316810.1158840060199.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-286?page=all ]

Kabir Khan closed JBAOP-286.
----------------------------

    Resolution: Done

> Weaken dependencies on unreleased MC 2.0
> ----------------------------------------
>
>                 Key: JBAOP-286
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-286
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 21 08:46:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 08:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10744703.1158842761945.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343731 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

-1 has no meaning for the default timeout but the clause should be changed.

The lower level action only understands
  0 == no timeout
  >0 == timeout


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 08:49:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 21 Sep 2006 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16972197.1158842940960.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343732 ] 
            
Mark Little commented on JBTM-116:
----------------------------------

Which lower level? JBossTS understands -1. It means "transactions never time out".

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:00:59 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 09:00:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <13098297.1158843659889.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment:     (was: jboss-aop-jdk50.jar)

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:01:00 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 09:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <29826673.1158843660069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment:     (was: jboss-aop.jar)

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:03:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28765978.1158843781347.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343733 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

Okay, just looked at the code again and I missed a step.

Setting the default timeout to 0 means that it defers to the default timeout in the property file.

So
 -1 = don't call the reaper (no timeout)
  0 = don't replace the property file value (i.e. use the property default)
 >0 = timeout

So the code in the mbean should read

public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
{
    if (timeout != 0)
    {
        TxControl.setDefaultTimeout(timeout);
    }
}

Ignore 0 and set the others.


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:15:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 09:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4690573.1158844501152.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343734 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

BTW The lower level was the transaction reaper code :-)

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:18:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 21 Sep 2006 09:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21591802.1158844681427.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343736 ] 
            
Mark Little commented on JBTM-116:
----------------------------------

Yes, but we don't add transactions to the reaper unless they have a non-zero timeout ;-)

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13474989.1158844861191.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343737 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

Ah but we do in at least one case, which is where the misunderstanding came from ;-)


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:25:58 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 09:25:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27631007.1158845158458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=all ]

Carlo de Wolf reassigned EJBTHREE-711:
--------------------------------------

    Assignee: Carlo de Wolf

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:37:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <30036724.1158845821227.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343739 ] 
            
Dimitris Andreadis commented on JBAS-3652:
------------------------------------------

Rajesh, working on this?

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:37:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28240820.1158845821418.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Dimitris Andreadis closed JBAS-3554.
------------------------------------

    Resolution: Done

It's done, I suppose.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:43:00 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <10829529.1158846180693.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343741 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Will get this in today.

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:45:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 09:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-9) Remove the dom4j
 dependency from org.jboss.util.state.xml.StateMachineParser
In-Reply-To: <11341338.1158763621358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4600967.1158846301140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-9?page=all ]

Dimitris Andreadis closed JBCOMMON-9.
-------------------------------------

    Resolution: Done

Done

> Remove the dom4j dependency from org.jboss.util.state.xml.StateMachineParser
> ----------------------------------------------------------------------------
>
>                 Key: JBCOMMON-9
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-9
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.0.0.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: 1.0.0.GA, 2.0.0.Beta
>
>
> StateMachineParser is the only class in the common package that has a dependency on dom4j.
> Re-write it so the dom4j dependency is removed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32274466.1158847201350.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3666?page=comments#action_12343744 ] 
            
Dimitris Andreadis commented on JBAS-3666:
------------------------------------------

So the standalone common module does not depend on dom4j anymore. This is currently accessed through snapshot-Branch_1_0, and will be part of jboss-common-1.0.0.GA

The jmx module now uses the jarjar org.jboss.dom4j version of dom4j, bundled in jboss-jmx.jar. The old dom4j lib is removed from JBOSS_HOME/lib.

The latest dom4j.jar lib is copied in JBOSS_HOME/server/all|default/lib, so modules like 'deployment' and 'console' that have minor dependencies on it can use it, plus user code that depended on dom4j will still work.

Updating dom4j / jaxen should now be easily done, if necessary.

> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-85) Add support for
 base64 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23442829.1158847201462.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBXB-85?page=comments#action_12343745 ] 
            
Heiko Braun commented on JBXB-85:
---------------------------------

I migrated the the org.jboss.test.xml.XOPUnitTestCase to the local test suite and added test methods for marshalling/unmarshalling simple xsd:base64Binary declarations.

> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28860513.1158847201583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3666?page=all ]

Dimitris Andreadis closed JBAS-3666.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBXB-85) Add support for
 base64 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16405029.1158847201812.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-85?page=all ]

Heiko Braun reassigned JBXB-85:
-------------------------------

    Assignee: Alexey Loubyansky

> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:06:01 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 21 Sep 2006 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
Message-ID: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support EJBContext injection through ejb-jar.xml
------------------------------------------------

                 Key: EJBTHREE-712
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
             Project: EJB 3.0
          Issue Type: Task
    Affects Versions: EJB 3.0 RC10 - FD
            Reporter: Bill Burke
         Assigned To: Carlo de Wolf


Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:19:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 10:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-549) Remoting
 2.2.0.Alpha1 breaks 2 crash tests
In-Reply-To: <11678719.1158799736606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7880735.1158848341198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-549?page=all ]

Clebert Suconic updated JBMESSAGING-549:
----------------------------------------

    Affects Version/s:     (was: 1.0.1.CR4)

It doesn't affect CR4

> Remoting 2.2.0.Alpha1 breaks 2 crash tests
> ------------------------------------------
>
>                 Key: JBMESSAGING-549
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> 1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115)
> 2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115)

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:40:00 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Thu, 21 Sep 2006 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-136) Define a set of EPRs
 for Email, Ftp and Database.
In-Reply-To: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26434763.1158849600393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-136?page=all ]

Arvinder Singh closed JBESB-136.
--------------------------------

    Resolution: Done

EPRs in xsd format together with basic examples and validation have been added. This task is ongoing and the epr xsds will evolve over time, for now there is a working skeleton with more details to be added

> Define a set of EPRs for Email, Ftp and Database.
> -------------------------------------------------
>
>                 Key: JBESB-136
>                 URL: http://jira.jboss.com/jira/browse/JBESB-136
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Arvinder Singh
>         Assigned To: Arvinder Singh
>             Fix For: 4.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:04:01 2006
From: jira-events at jboss.com (Britt Miner (JIRA))
Date: Thu, 21 Sep 2006 11:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-753) Leaving a
 Superstate does not record a NodeLog
In-Reply-To: <11880179.1158597657146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4607958.1158851041098.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-753?page=comments#action_12343760 ] 
            
Britt Miner commented on JBPM-753:
----------------------------------

Till then, I've posted a brute force work-around ( http://wiki.jboss.org/wiki/Wiki.jsp?page=Jbpm_SuperStateNodeLogAH ) that gets a Superstate NodeLog recorded for the sake of reporting and statusing performance.

> Leaving a Superstate does not record a NodeLog
> ----------------------------------------------
>
>                 Key: JBPM-753
>                 URL: http://jira.jboss.com/jira/browse/JBPM-753
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM 3.1.2
>            Reporter: Britt Miner
>         Assigned To: Tom Baeyens
>
> Leaving a Superstate should persist a NodeLog, but doesn'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

        


From jira-events at jboss.com  Thu Sep 21 11:06:01 2006
From: jira-events at jboss.com (Thomas Heute (JIRA))
Date: Thu, 21 Sep 2006 11:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPTL-51) Have a different page
 to change password
Message-ID: <24662672.1158851161324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-51?page=all ]

Thomas Heute updated JBPTL-51:
------------------------------

    Attachment: JBPTL-51.zip

Contribution of Benjamin Lerer

Thanks !

> Have a different page to change password
> ----------------------------------------
>
>                 Key: JBPTL-51
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-51
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>            Reporter: Thomas Heute
>            Priority: Optional
>         Attachments: JBPTL-51.zip
>
>   Original Estimate: 1 hour, 30 minutes
>  Remaining Estimate: 1 hour, 30 minutes
>
> Just to make it more convenient, a different page (than the edit profile page) to change the password would be nice.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:06:01 2006
From: jira-events at jboss.com (Britt Miner (JIRA))
Date: Thu, 21 Sep 2006 11:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-288) Fork/Join and child
 token deactivation
Message-ID: <1165498.1158851161974.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-288?page=comments#action_12343762 ] 
            
Britt Miner commented on JBPM-288:
----------------------------------

For anyone experiencing this problem, I've posted a work-around here http://wiki.jboss.org/wiki/Wiki.jsp?page=Jbpm_EndForkedTokensAH.

> Fork/Join and child token deactivation
> --------------------------------------
>
>                 Key: JBPM-288
>                 URL: http://jira.jboss.com/jira/browse/JBPM-288
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.0
>         Environment: Any
>            Reporter: Lukasz Czekierda
>         Assigned To: Tom Baeyens
>         Attachments: processdefinition.xml, SimpleProcessTest.java
>
>
> Join implementation has incorrectly/no implemented activation of finished child tokens. They remain active till the end of the whole process.  Example from junit test (Wfp03SynchronizationTest.testSynchronizationFirstTokenFirst) works perfectly as long as is unmodified. After adding a few bottom lines and changing a transition in join I get my error. Token.end is called on children and the root token in the LAST state, when finishing the entire process. When in stateX or stateY, the process still reports two active child tokens. 
>  --- 
> "<process-definition>" + 
> " <start-state name='start'>" + 
> " <transition to='fork' />" + 
> " </start-state>" + 
> " <fork name='fork'>" + 
> " <transition name='first' to='one' />" + 
> " <transition name='second' to='two' />" + 
> " </fork>" + 
> " <state name='one'>" + 
> " <transition to='join' />" + 
> " </state>" + 
> " <state name='two'>" + 
> " <transition to='join' />" + 
> " </state>" + 
> " <join name='join'>" + 
> " <transition to='stateX' />" + 
> " </join>" + 
> " <state name='stateX'>" + 
> " <transition to='stateY' />" + 
> " </state>" + 
> " <state name='stateY'>" + 
> " <transition to='end' />" + 
> " </state>" +
> " <end-state name='end' />" + 
> "</process-definition>" 

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:09:00 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 11:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
Message-ID: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>

If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
-------------------------------------------------------------------------------------

                 Key: JBREM-602
                 URL: http://jira.jboss.com/jira/browse/JBREM-602
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
         Assigned To: Tom  Elrod
            Priority: Blocker
             Fix For: 2.2.0.Beta1 (Bluto)


this will cause an exception setting up the Timer as the Timer doesn't accept negative values.


This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:18:01 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Thu, 21 Sep 2006 11:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3644) ejbqltosql92compiler
 creates LEFT OUTER JOIN when INNER JOIN would be faster
In-Reply-To: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28417885.1158851881680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3644?page=all ]

anajavi updated JBAS-3644:
--------------------------

    Attachment: EJBQLToSQL92Compiler.java

Modified version of EJBQLToSQL92Compiler. This version tries to use INNER JOIN where possible. It needs also two boolean fields added to ASTPath:
   public boolean forceLeftJoin;
   public boolean wherePath;

> ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
>            Reporter: anajavi
>         Assigned To: Alexey Loubyansky
>         Attachments: EJBQLToSQL92Compiler.java
>
>
> Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 
> Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
> I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
> I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
> I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
> Example:
> Original EJBQL:
> SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
> Generated SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'
> 10x faster SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
> Thank you.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:23:00 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Thu, 21 Sep 2006 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3644) ejbqltosql92compiler
 creates LEFT OUTER JOIN when INNER JOIN would be faster
In-Reply-To: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1915831.1158852180370.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3644?page=all ]

anajavi updated JBAS-3644:
--------------------------

    Attachment: ASTPath.java

> ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
>            Reporter: anajavi
>         Assigned To: Alexey Loubyansky
>         Attachments: ASTPath.java, EJBQLToSQL92Compiler.java
>
>
> Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 
> Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
> I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
> I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
> I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
> Example:
> Original EJBQL:
> SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
> Generated SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'
> 10x faster SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
> Thank you.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:23:00 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <182475.1158852180525.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-602?page=comments#action_12343764 ] 
            
Clebert Suconic commented on JBREM-602:
---------------------------------------

There is a default being treated.
But in an unknown situation the default is also set to -1.

I"m still investigating

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:24:58 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 21 Sep 2006 11:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1052) Build taking too
 long and moving too many files around.
Message-ID: <12400934.1158852298838.JavaMail.jira@cloud.prod.atl2.jboss.com>

Build taking too long and moving too many files around.
-------------------------------------------------------

                 Key: JBPORTAL-1052
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1052
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


a 5  minute build is not necessary!

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:28:05 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Thu, 21 Sep 2006 11:28:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3644)
 ejbqltosql92compiler creates
 LEFT OUTER JOIN when INNER JOIN would be faster
In-Reply-To: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13684849.1158852485454.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3644?page=comments#action_12343765 ] 
            
anajavi commented on JBAS-3644:
-------------------------------

Modified version of compiler works as follows:
1. visiting ASTWhere node sets wherePath=true in all ASTWhere's child paths.
2. visiting ASTOr, ASTNullComparison or ASTIsEmpty causes their child paths to have forceLeftJoin=true
3. When visiting ASTPath compiler checks if wherePath is true and adds join based on forceLeftJoin field. If wherePath is false compiler works as before.
4. If some path has forceLeftJoin set, it cannot be reset to innerjoin

Otherwise the compiler works as before.

Is there something i'm missing or can this be added to default JBoss?

This really boosted performance for us.


> ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
>            Reporter: anajavi
>         Assigned To: Alexey Loubyansky
>         Attachments: ASTPath.java, EJBQLToSQL92Compiler.java
>
>
> Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 
> Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
> I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
> I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
> I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
> Example:
> Original EJBQL:
> SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
> Generated SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'
> 10x faster SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
> Thank you.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:03:59 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Thu, 21 Sep 2006 12:03:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4209363.1158854639511.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-602?page=comments#action_12343770 ] 
            
Tom  Elrod commented on JBREM-602:
----------------------------------

Only place I can see where the pingPeriod value for the timer would be set to a negative value would be within:

LeasePinger.removeClient(String sessionId)

where it walks through the lease period for all client configs and sees if need to reset the ping period.  I have checked in code change for this to ensure never gets set to negative value.  

Don't know if this is the exact error you are seeing, but only place I can see where it could happen.

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:12:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 12:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1732982.1158855121627.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-602?page=comments#action_12343771 ] 
            
Clebert Suconic commented on JBREM-602:
---------------------------------------

The condition for this to happen was:

Server.leasePeriod was set to -1 (hoping to disable lease)

( 
      //Set lease period to -1 --> this should disable leasing so the state won't be cleared up
      //localServer.setAttribute(ServiceContainer.REMOTING_OBJECT_NAME, "LeasePeriod", "-1");
)


Then lease was enabled on the client, a $PING$ was executed.
Lease=-1 was used as the default LeasePeriod (what is not valid for Timers)

       


> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:27:04 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 12:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-288) Unify API used by
 AspectDeployer with AOP 2.0
Message-ID: <16584240.1158856024495.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unify API used by AspectDeployer with AOP 2.0
---------------------------------------------

                 Key: JBAOP-288
                 URL: http://jira.jboss.com/jira/browse/JBAOP-288
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 1.5.2.GA


The AspectDeployer will be built from Branch_4_0 for both AOP 1.5.x and AOP 2.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

        


From jira-events at jboss.com  Thu Sep 21 12:43:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 12:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11712520.1158856981740.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-602?page=all ]

Clebert Suconic updated JBREM-602:
----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973336#3973336

Lets use the forum thread to discuss the bug

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:58:01 2006
From: jira-events at jboss.com (Michael Voss (JIRA))
Date: Thu, 21 Sep 2006 12:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-603) Servers alternately
 discoverd and detected as gone when using ssl
Message-ID: <31645697.1158857881121.JavaMail.jira@cloud.prod.atl2.jboss.com>

Servers alternately discoverd and detected as gone when using ssl
-----------------------------------------------------------------

                 Key: JBREM-603
                 URL: http://jira.jboss.com/jira/browse/JBREM-603
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: detection
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Michael Voss
         Assigned To: Tom  Elrod
            Priority: Critical


When server uses a ssl sconnector the client discovers the new server and detected it has gone and then again discovered and so on
can try it with classes from package org.jboss.remoting.samples.detection.jndi changing transport to sslsocket or multiplex

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:01:01 2006
From: jira-events at jboss.com (Michael Voss (JIRA))
Date: Thu, 21 Sep 2006 13:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-603) Servers alternately
 discoverd and detected as gone when using ssl
In-Reply-To: <31645697.1158857881121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4529875.1158858061342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-603?page=all ]

Michael Voss updated JBREM-603:
-------------------------------

    Attachment: SSL-Detection.zip

(classses are not in a package)

> Servers alternately discoverd and detected as gone when using ssl
> -----------------------------------------------------------------
>
>                 Key: JBREM-603
>                 URL: http://jira.jboss.com/jira/browse/JBREM-603
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: detection
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Michael Voss
>         Assigned To: Tom  Elrod
>            Priority: Critical
>         Attachments: SSL-Detection.zip
>
>
> When server uses a ssl sconnector the client discovers the new server and detected it has gone and then again discovered and so on
> can try it with classes from package org.jboss.remoting.samples.detection.jndi changing transport to sslsocket or multiplex

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:15:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 21 Sep 2006 13:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1052) Build taking
 too long and moving too many files around.
In-Reply-To: <12400934.1158852298838.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2913328.1158858901354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1052?page=all ]

Roy Russo resolved JBPORTAL-1052.
---------------------------------

    Resolution: Won't Fix

This is unfixable with the build we have currently.

> Build taking too long and moving too many files around.
> -------------------------------------------------------
>
>                 Key: JBPORTAL-1052
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1052
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> a 5  minute build is not necessary!

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:33:00 2006
From: jira-events at jboss.com (Wenbo Zhu (JIRA))
Date: Thu, 21 Sep 2006 13:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-713)
 META-INF/jboss-service.xml
 doesn't apply to POJO service bean  (ie. allow to configure POJO service
 bean attributes at deployment time)
Message-ID: <1614383.1158859980865.JavaMail.jira@cloud.prod.atl2.jboss.com>

META-INF/jboss-service.xml doesn't apply to POJO service bean  (ie. allow to configure POJO service bean attributes at deployment time)
---------------------------------------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-713
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-713
             Project: EJB 3.0
          Issue Type: Bug
          Components: EJB3 Extensions
    Affects Versions: EJB 3.0 RC7 - FD
         Environment: JBoss App Server 4.0.4 GA release.
            Reporter: Wenbo Zhu


META-INF/jboss-service.xml is not used when deploying POJO service bean. Also, the EJB3 guide examples contain a dummy jboss-service.xml under META-INF, which should be cleaned up (if not supported).

As this is not part of ejb3 standards, it could be just a feature request - to allow using descriptor file for configuring mbean attrs.



-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:44:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Thu, 21 Sep 2006 13:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26132842.1158860641069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3666?page=all ]

Scott M Stark reopened JBAS-3666:
---------------------------------

      Assignee: Scott M Stark  (was: Dimitris Andreadis)
             
The current 4.0 build is failing with errors like:

2006-09-21 10:25:42,343 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:war=invoker.war,id=1836912571
java.lang.NoClassDefFoundError: org/dom4j/DocumentException
	at org.jboss.security.jacc.JBossPolicyConfigurationFactory.<init>(JBossPolicyConfigurationFactory.java:57)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
	at java.lang.Class.newInstance0(Class.java:350)
	at java.lang.Class.newInstance(Class.java:303)
	at javax.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory(PolicyConfigurationFactory.java:91)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:351)
	at org.jboss.web.WebModule.startModule(WebModule.java:83)
	at org.jboss.web.WebModule.startService(WebModule.java:61)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)

This particular case is due to the jboss/common snapshot-Branch_1_0 still having dom4j dependencies? I'm looking into it.



> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:12:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Thu, 21 Sep 2006 14:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3441969.1158862321708.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3666?page=all ]

Scott M Stark closed JBAS-3666.
-------------------------------

    Resolution: Done

The problem was the reuse of a snapshot release in the build resulting in the local build repository not being in synch with the version described by this issue. Snapshots are evil.


> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:15:01 2006
From: jira-events at jboss.com (Moises Quinto (JIRA))
Date: Thu, 21 Sep 2006 14:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9213197.1158862501264.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-98?page=comments#action_12343778 ] 
            
Moises Quinto commented on JBTM-98:
-----------------------------------

what is the setup of your test? If I have a single JBoss server talking to oracle then it works fine. When I try the following scenario is when I get the problem (both server 4.0.3 SP1 and JBossts 4.2):

Server1 : starts the global distributed transaction, performs local oracle database operations and calls a server2Bean on server2

// this method has the tx "required" attribute in ejb-jar.xml
performGlobalTx(){
  doSomething(); // do oracle operations
  server2Bean.doSomething(); // call remote jboss Server2
}

Server2: the bean on this server updates the same oracle database:

doSomething(){
   performDBOperations...;
  // here is where I get the exceptions reported in the forum <<<<--------------------here
}


> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:49:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 14:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3682) Upgrade jboss aop to
	1.5.2.GA
Message-ID: <2301715.1158864541102.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss aop to 1.5.2.GA
-----------------------------

                 Key: JBAS-3682
                 URL: http://jira.jboss.com/jira/browse/JBAS-3682
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 21 14:55:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 21 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2409) EJB3 JMS
	Integration
Message-ID: <22040590.1158864901603.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2409?page=comments#action_12343779 ] 
            
William DeCoste commented on JBAS-2409:
---------------------------------------

As of EJB3 RC9, all the legacy EJB3 JMS code has been removed in favor of using the jms resource adaptor -except the code to create temporary queues, which the adaptor does not currently support.

> EJB3 JMS Integration
> --------------------
>
>                 Key: JBAS-2409
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2409
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>         Assigned To: William DeCoste
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to determine whether the legacy JMS MDB integration using ServerSessionPools directly
> needs to be refactored to cover both EJB2.1 and EJB3.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

        


From jira-events at jboss.com  Thu Sep 21 14:55:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 21 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-324) Ethereal plugin for
	JGroups
Message-ID: <25242656.1158864901723.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ethereal plugin for JGroups
---------------------------

                 Key: JGRP-324
                 URL: http://jira.jboss.com/jira/browse/JGRP-324
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.x


Write a C implementation of an ethereal plugin which understands the JGroups wire format and displays information about the JGroups messages (e.g. sender, receiver, headers) in ethereal.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:55:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 21 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2409) EJB3 JMS Integration
Message-ID: <19272286.1158864901917.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2409?page=all ]

William DeCoste closed JBAS-2409.
---------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.6.CR1)
       Resolution: Done

> EJB3 JMS Integration
> --------------------
>
>                 Key: JBAS-2409
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2409
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>         Assigned To: William DeCoste
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to determine whether the legacy JMS MDB integration using ServerSessionPools directly
> needs to be refactored to cover both EJB2.1 and EJB3.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

        


From jira-events at jboss.com  Thu Sep 21 14:55:02 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 21 Sep 2006 14:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <19129409.1158864902117.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Ryan Campbell moved ASPATCH-78 to JBAS-3683:
--------------------------------------------

              Project: JBoss Application Server  (was: JBoss AS Patches)
                  Key: JBAS-3683  (was: ASPATCH-78)
    Affects Version/s: JBossAS-4.0.4.GA
                           (was: JBossAS-4.0.4.GA)

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Ryan Campbell
>            Priority: Trivial
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:57:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 21 Sep 2006 14:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <9288223.1158865021293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Ryan Campbell updated JBAS-3683:
--------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Ryan Campbell
>            Priority: Trivial
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:57:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 21 Sep 2006 14:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <16553872.1158865021477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Ryan Campbell reassigned JBAS-3683:
-----------------------------------

    Assignee:     (was: Ryan Campbell)

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>            Priority: Trivial
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 15:30:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 15:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-288) Unify API used by
 AspectDeployer with AOP 2.0
In-Reply-To: <16584240.1158856024495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12908310.1158867001072.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-288?page=all ]

Kabir Khan closed JBAOP-288.
----------------------------

    Resolution: Done

> Unify API used by AspectDeployer with AOP 2.0
> ---------------------------------------------
>
>                 Key: JBAOP-288
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-288
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 1.5.2.GA
>
>
> The AspectDeployer will be built from Branch_4_0 for both AOP 1.5.x and AOP 2.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

        


From jira-events at jboss.com  Thu Sep 21 15:33:02 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 15:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <12348861.1158867182342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343783 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Just the text file should be added? what about doc and pdf? they are all the same.
Should this go in HEAD as well?

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 15:33:02 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 15:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <8750843.1158867182690.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343785 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Ah. the task description says just the text file. OK

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 15:36:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 15:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3682) Upgrade jboss aop to
	1.5.2.GA
In-Reply-To: <2301715.1158864541102.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32172928.1158867361050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3682?page=all ]

Kabir Khan closed JBAS-3682.
----------------------------

    Resolution: Done

> Upgrade jboss aop to 1.5.2.GA
> -----------------------------
>
>                 Key: JBAS-3682
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3682
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 21 15:44:00 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 15:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <8437007.1158867840825.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Rajesh Rajasekaran resolved JBAS-3652.
--------------------------------------

    Resolution: Done

jboss-release.xml modified to bundle JBossEULA.txt in all distributions

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 16:18:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 16:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <33447608.1158869881328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Description: 
Provide a HTTP invoker initial configuration and a working example.
Add the example to docs/examples so it can be used as an integration test.

Reviewed requirements:

1. The messaging client needs to connect to the server over HTTP
2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.


  was:
Provide a HTTP invoker initial configuration and a working example.
Add the example to docs/examples so it can be used as an integration test.


> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 16:30:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 16:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <17990787.1158870601250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91135  (was: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=74846)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 17:13:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 17:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-551) Upgrade JBoss
	Remoting
Message-ID: <11467857.1158873181765.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade JBoss Remoting
----------------------

                 Key: JBMESSAGING-551
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-551
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.0.1.CR5


Upgrade JBoss Remoting to a version containing JBREM-602 fixed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 17:43:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 17:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-547) Upgrade
 JBossSerialization to 1.0.3.GA
In-Reply-To: <24696517.1158689157470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27518668.1158874981200.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-547?page=all ]

Clebert Suconic closed JBMESSAGING-547.
---------------------------------------

    Resolution: Done

> Upgrade JBossSerialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBMESSAGING-547
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> I will do it as soon as the release is out.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 18:42:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 18:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-551) Upgrade JBoss
	Remoting
In-Reply-To: <11467857.1158873181765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3051892.1158878577794.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-551?page=all ]

Ovidiu Feodorov closed JBMESSAGING-551.
---------------------------------------

    Resolution: Done

> Upgrade JBoss Remoting
> ----------------------
>
>                 Key: JBMESSAGING-551
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-551
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Upgrade JBoss Remoting to a version containing JBREM-602 fixed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 18:43:03 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 18:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-549) Remoting
 2.2.0.Alpha1 breaks 2 crash tests
In-Reply-To: <11678719.1158799736606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8694616.1158878583024.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-549?page=all ]

Ovidiu Feodorov closed JBMESSAGING-549.
---------------------------------------

    Resolution: Done

> Remoting 2.2.0.Alpha1 breaks 2 crash tests
> ------------------------------------------
>
>                 Key: JBMESSAGING-549
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> 1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115)
> 2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115)

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 19:07:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Thu, 21 Sep 2006 19:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1053) WSRP URLs are
 improperly un-escaped in situations where they should be.
Message-ID: <4032852.1158880021204.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP URLs are improperly un-escaped in situations where they should be.
-----------------------------------------------------------------------

                 Key: JBPORTAL-1053
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1053
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 21 19:15:07 2006
From: jira-events at jboss.com (Mark Menard (JIRA))
Date: Thu, 21 Sep 2006 19:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-553) PrePersist
 callback method not called if entity's primery key is null
Message-ID: <2981533.1158880507532.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-553?page=comments#action_12343792 ] 
            
Mark Menard commented on EJBTHREE-553:
--------------------------------------

I'm also having this issue, setting my id in the @PrePersist method, and I'm going to apply Michal's patch to Hibernate to work around it.

I would like to ask though is this the way it is supposed to work? Or should we just not generate ids in the @PrePersist method? 

> PrePersist callback method not called if entity's primery key is null
> ---------------------------------------------------------------------
>
>                 Key: EJBTHREE-553
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-553
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jboss-4.0.4.CR2
>            Reporter: Michal Borowiecki
>
> When an entity is persisted which does not have its primary key set (and it is not annotated with GeneratedValue annotation), the @PrePersist callback method is not invoked. 
> Instead the exception is thrown:
> Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): com.bluemedia.system.User
> 	at org.hibernate.id.Assigned.generate(Assigned.java:33)
> 	at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98)
> 	at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
> 	at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:617)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:591)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:595)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:187)
> 	... 64 more
> This is in conflict with ejb 3.0-pfd spec, which states (sec. 3.4.2) :
> "The PrePersist and PreRemove callback methods are invoked for a given entity before the respective EntityManager persist and remove operations for that entity are executed."
> Since the spec states that EntityManager's persist operation is executed after the PrePersist callback methods, setting the value of the primary key in a PrePersist callback method seems a reasonable use case.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:28:58 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Thu, 21 Sep 2006 20:28:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-326) Some queries
 are slower when executed in JBoss EJB3
Message-ID: <3755811.1158884938881.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-326?page=comments#action_12343793 ] 
            
Emmanuel Bernard commented on EJBTHREE-326:
-------------------------------------------

We have discovered an important unefficiency (n**2 class) in HEM flush algorithm, do you happen to have lot's of cascade (even bidirectional ones)?

> Some queries are slower when executed in JBoss EJB3
> ---------------------------------------------------
>
>                 Key: EJBTHREE-326
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-326
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC3
>         Environment: JBoss4.0.3 rc2
>            Reporter: J-C jc
>         Assigned To: Emmanuel Bernard
>
> When a lot of objects have been resolved in the current transaction, queries becomes slow. see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68954&postdays=0&postorder=asc&start=0 for more details.
> More generally, it seems that EJB3 persistence access is slower in JBoss EJB3 compare to access in EJB3 outside of JBoss:
> see http://forum.hibernate.org/viewtopic.php?t=948850

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:31:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Thu, 21 Sep 2006 20:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19180110.1158885061685.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=all ]

Emmanuel Bernard reassigned EJBTHREE-649:
-----------------------------------------

    Assignee: Emmanuel Bernard

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:31:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Thu, 21 Sep 2006 20:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23644986.1158885061920.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343794 ] 
            
Emmanuel Bernard commented on EJBTHREE-649:
-------------------------------------------

We have discovered an important unefficiency (n**2 class) in HEM flush algorithm, do you happen to have lot's of cascade (even bidirectional ones)?

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:47:00 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 20:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28294710.1158886020436.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Clebert Suconic reassigned JBMESSAGING-545:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:57:01 2006
From: jira-events at jboss.com (Chris Rudd (JIRA))
Date: Thu, 21 Sep 2006 20:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-308) DataModel
 instance changes
 even though the backing list did not when using PAGE scope
In-Reply-To: <29938082.1152829515513.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28541944.1158886621114.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-308?page=comments#action_12343795 ] 
            
Chris Rudd commented on JBSEAM-308:
-----------------------------------

Yes this issue causes the behavior that is described in the thread.

> DataModel instance changes even though the backing list did not when using PAGE scope
> -------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-308
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-308
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>            Reporter: Chris Rudd
>
> The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected.
> When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. 
> The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. 
> I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection.
> I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ):
>  private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper)
>    {
>       
>       Context context = getDataModelContext(scope);
>       Object existingDataModel = context.get(name);
>       boolean dirty = existingDataModel == null || 
>             !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality
>       
>       if ( dirty )
>       {
>          if ( list != null )
>          {
>             context.set( name, wrapper.wrap(list) );
>          }
>          else
>          {
>             context.remove( name );
>          }
>       }
>       // If page scope, outject the existingDataModel even if there was no change
>       else if( scope==ScopeType.PAGE )
>       {
>          context.set( name, existingDataModel );
>       }
>       
>    }

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 21:05:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 21:05:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
Message-ID: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>

MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
---------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-552
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Beta1


Logs Attached

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 21:08:00 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 21:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
In-Reply-To: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1964201.1158887280034.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-552?page=all ]

Ovidiu Feodorov updated JBMESSAGING-552:
----------------------------------------

    Attachment: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log

> MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-552
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>         Attachments: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log, MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log
>
>
> Logs Attached

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 21:08:00 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 21:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
In-Reply-To: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5202883.1158887280176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-552?page=all ]

Ovidiu Feodorov updated JBMESSAGING-552:
----------------------------------------

    Attachment: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log

> MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-552
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>         Attachments: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log, MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log
>
>
> Logs Attached

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 22:00:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 22:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5846955.1158890401262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Clebert Suconic updated JBMESSAGING-545:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973448#3973448

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 22:36:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 22:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28469859.1158892561353.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Clebert Suconic closed JBMESSAGING-545.
---------------------------------------

    Resolution: Done

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 23:27:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Thu, 21 Sep 2006 23:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13528298.1158895621181.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-602?page=all ]

Tom  Elrod resolved JBREM-602.
------------------------------

    Resolution: Done

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 00:30:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 00:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3684) References to
	TxManager
Message-ID: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>

References to TxManager
-----------------------

                 Key: JBAS-3684
                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Kevin Conner
         Assigned To: Bill Burke
            Priority: Critical


The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.

      ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
      ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java

These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 00:35:00 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 00:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3685) References to
	TxManager
Message-ID: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>

References to TxManager
-----------------------

                 Key: JBAS-3685
                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Kevin Conner
            Priority: Critical


The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.

   aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java

These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.

Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
===================================================================
--- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
@@ -26,6 +26,7 @@
 import org.jboss.aop.advice.Interceptor;
 import org.jboss.aop.joinpoint.Invocation;
 import org.jboss.logging.Logger;
+import org.jboss.tm.TransactionTimeoutConfiguration;

 /**
  * This interceptor handles transactions for AOP
@@ -174,20 +175,18 @@

       public Object invoke(Invocation invocation) throws Throwable
       {
-         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
          int oldTimeout = 0;

-         if (tm instanceof org.jboss.tm.TxManager)
+         if (tm instanceof TransactionTimeoutConfiguration)
          {
-            txManager = (org.jboss.tm.TxManager)tm;
-            oldTimeout = txManager.getTransactionTimeout();
+            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
          }

          try
          {
-            if (timeout != -1 && txManager != null)
+            if (timeout != -1 && tm != null)
             {
-               txManager.setTransactionTimeout(timeout);
+               tm.setTransactionTimeout(timeout);
             }

             Transaction tx = tm.getTransaction();
@@ -203,9 +202,9 @@
          }
          finally
          {
-            if (txManager != null)
+            if (tm != null)
             {
-               txManager.setTransactionTimeout(oldTimeout);
+               tm.setTransactionTimeout(oldTimeout);
             }
          }
       }
@@ -241,20 +240,18 @@

       public Object invoke(Invocation invocation) throws Throwable
       {
-         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
          int oldTimeout = 0;

-         if (tm instanceof org.jboss.tm.TxManager)
+         if (tm instanceof TransactionTimeoutConfiguration)
          {
-            txManager = (org.jboss.tm.TxManager)tm;
-            oldTimeout = txManager.getTransactionTimeout();
+            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
          }

          try
          {
-            if (timeout != -1 && txManager != null)
+            if (timeout != -1 && tm != null)
             {
-               txManager.setTransactionTimeout(timeout);
+               tm.setTransactionTimeout(timeout);
             }

             Transaction tx = tm.getTransaction();
@@ -277,9 +274,9 @@
          }
          finally
          {
-            if (txManager != null)
+            if (tm != null)
             {
-               txManager.setTransactionTimeout(oldTimeout);
+               tm.setTransactionTimeout(oldTimeout);
             }
          }
       }


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 02:46:06 2006
From: jira-events at jboss.com (J-C jc (JIRA))
Date: Fri, 22 Sep 2006 02:46:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9116192.1158907566186.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343796 ] 
            
J-C jc commented on EJBTHREE-649:
---------------------------------

That's happen when I have a lot of cascade. My solution has to reduce as much as possible this cascade. It improves the performance but it is sometimes a little more complex to implement and bug prone.
When I tried to investigate a little more the problem (http://opensource.atlassian.com/projects/hibernate/browse/HHH-1207), I go into the hibernate flush  and more specificly the flush on collections.
That's not easy to debug, so as just changing the cascade type solve my problem I have stopped investiagtions.

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 02:52:01 2006
From: jira-events at jboss.com (J-C jc (JIRA))
Date: Fri, 22 Sep 2006 02:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-326) Some queries
 are slower when executed in JBoss EJB3
Message-ID: <6946343.1158907921497.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-326?page=comments#action_12343797 ] 
            
J-C jc commented on EJBTHREE-326:
---------------------------------

I had this problem with old release of JBoss EJB3 (rc2). I do not check if it is always true with last release.

Problem was that queries was slower inside JBoss AS than using EJB3 persistence outside of JBoss AS (in a standalone application).  This issue is probably not the same as http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12340482. Problem is probably in the integration of HEM with the JBoss AS.

> Some queries are slower when executed in JBoss EJB3
> ---------------------------------------------------
>
>                 Key: EJBTHREE-326
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-326
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC3
>         Environment: JBoss4.0.3 rc2
>            Reporter: J-C jc
>         Assigned To: Emmanuel Bernard
>
> When a lot of objects have been resolved in the current transaction, queries becomes slow. see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68954&postdays=0&postorder=asc&start=0 for more details.
> More generally, it seems that EJB3 persistence access is slower in JBoss EJB3 compare to access in EJB3 outside of JBoss:
> see http://forum.hibernate.org/viewtopic.php?t=948850

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 03:55:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 03:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-322) Provide 3 major
 default configurations (udp.xml, tcp.xml and tcp-nio.xml)
In-Reply-To: <7218240.1158479447973.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21183344.1158911701342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-322?page=all ]

Bela Ban updated JGRP-322:
--------------------------

    Fix Version/s: 2.4
                       (was: 2.2.9 SP4)

> Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)
> -------------------------------------------------------------------------
>
>                 Key: JGRP-322
>                 URL: http://jira.jboss.com/jira/browse/JGRP-322
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> Those configs should be the same in stacks.xml (for the Multiplexer) as well

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 03:55:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 03:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31993198.1158911701903.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=all ]

Carlo de Wolf resolved EJBTHREE-711.
------------------------------------

    Resolution: Done

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 04:13:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 04:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
Message-ID: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>

EvictionPolicyProvider WARN message is noisy and misleading
-----------------------------------------------------------

                 Key: JBCACHE-776
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
            Reporter: Galder Zamarreno
         Assigned To: Manik Surtani


JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
variable to hold eviction policies. The usage of this variable has been deprecated, but 
JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.

Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :

"Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
for 1.2.x backward compatibility and may disappear in future releases."

This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 04:43:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27749429.1158914581319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno reassigned JBCACHE-776:
----------------------------------------

    Assignee: Galder Zamarreno  (was: Manik Surtani)

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 04:43:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21062870.1158914581498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno updated JBCACHE-776:
-------------------------------------

    Priority: Minor  (was: Major)

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:01:01 2006
From: jira-events at jboss.com (tbech (JIRA))
Date: Fri, 22 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3399) Transaction
 timeout fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10297404.1158915661475.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3399?page=comments#action_12343798 ] 
            
tbech commented on JBAS-3399:
-----------------------------

There is no need to use JBossTM, it is already implemented in standard JTA. In fact it just appeared in 4.0.3, but the main documenation is not up to date. Finally found this: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigDataSources.

<set-tx-query-timeout> - whether to enable query timeout based on the length of time remaining until the transaction times out (default false - NOTE: This was NOT ported to 4.0.x until 4.0.3)

Sorry that I didn't use forum before.

> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:25:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 05:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1571614.1158917101383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3597?page=comments#action_12343799 ] 
            
Dimitris Andreadis commented on JBAS-3597:
------------------------------------------

The test is performed against a Branch_3_2 latest server using the following clients:

3.2.6
3.2.7
3.2.8
3.2.8.SP1
3.2.x (latest)
4.0.2
4.0.3
4.0.3.SP1
4.0.4.GA
4.0.x (latest)

Different runs produce different failures, eg.
4.0.4.GA

3.2.8
4.0.0.GA

4.0.4.GA.
4.0.x

3.2.8.SP1
4.0.4.GA.
4.0.x

3.2.8.SP1
4.0.4.GA

The only common denominator seems to be that 4.0.4.GA always fails


> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:25:01 2006
From: jira-events at jboss.com (Andreas Zimmer (JIRA))
Date: Fri, 22 Sep 2006 05:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8800069.1158917101765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343800 ] 
            
Andreas Zimmer commented on EJBTHREE-649:
-----------------------------------------

To Emmanuel's question on cascading relations: Yes, the scenario was with a Entity Pojo with cascading UNIdirectional relations, BUT the relations have NOT been filled, just a few String attributes got values. So in the concrete test scenario, no relation handling should have been required. 

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:31:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 05:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3325) Remove old code
Message-ID: <13522545.1158917461525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3325?page=all ]

Dimitris Andreadis updated JBAS-3325:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Remove old code
> ---------------
>
>                 Key: JBAS-3325
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3325
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: JBoss 4.0.3.SP1
> $ java -version
> java version "1.4.2_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
> $ java -version
> java version "1.5.0_07"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
>            Reporter: Robert Schroeder
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingJBossBehindAFirewall mentions the parameter "java.rmi.server.hostname" to set if the external host name differs from the local host (e.g. server machine is behind a firewall)
> But org.jboss.web.WebService doesn'r recognize this parameter:
>       String hostname = server.getBindAddress(); // this always returns something, at least "0.0.0.0"!
>       // If not user specified hostname given, then try to determine what it should be
>       if (hostname == null) //this branch is never executed!
>       {
>          // First look for the rmi server name
>          try
>          {
>             hostname = System.getProperty("java.rmi.server.hostname");  // this parameter is not recognized as this branch is never executed
>          }
>          catch (SecurityException e)
>          {
>             // ignore, but don't be silent
>             ThrowableHandler.addWarning(e);
>          }
>          // else use the localhost name
>          if (hostname == null)
>          {
>             try
>             {
>                hostname = InetAddress.getLocalHost().getHostName();
>             }
>             catch (IOException e)
>             {
>                log.error("Failed to get localhost name; ignoring", e);
>             }
>          }
>          if (hostname != null)
>          {
>             setHost(hostname);
>          }
>       }
>       // Host must be set to continue (either by user or detection)
>       String address = getHost();
>       if (address == null)
>          throw new MissingAttributeException("Host");
>       // Set the rmi codebase if it is not already set
>       String codebase = System.getProperty("java.rmi.server.codebase");
>       if (codebase == null)
>       {
>          address = ServerConfigUtil.fixRemoteAddress(address);
>          codebase = "http://" + address + ":" + getPort() + "/";
>          System.setProperty("java.rmi.server.codebase", codebase);
>       }
>       log.info("Using RMI server codebase: " + codebase);
> So the resulting problem is that codebase contains an address which is not reachable from the other side of firewall because "java.rmi.server.hostname" is not recognized (same for "-Djava.rmi.server.useLocalHostname=false" )
> Example:
> JBoss started with parameter set "-Djava.rmi.server.hostname=as2.subdomain1.subdomain2.test.com"
> but (thanks to rmi logging) the proxy objects on client side have codebase set to "http://as2:<port>" and not to "http://as2.subdomain1.subdomain2.test.com:<port>" as expected.
> JBoss 4 runs on a linux machine
> hostname --> "as2"
> hostname -f --> "as2.subdomain1.subdomain2.test.com"

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:34:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 05:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28760284.1158917641311.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3597?page=comments#action_12343801 ] 
            
Dimitris Andreadis commented on JBAS-3597:
------------------------------------------

The reverse tests (4.0-compatibility) that test a variety of clients against a latest Branch_4_0 server, sometimes pass, sometimes produce errors:

Client
3.2.8.SP1
4.0.4.GA

4.0.4.GA
4.0.x (latest)

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:43:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3679) BMP entitybeans cause
	db-deadlocks
In-Reply-To: <29336818.1158820441651.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13878494.1158918181985.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3679?page=all ]

Adrian Brock closed JBAS-3679.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Adrian Brock)

Wrong.

If you don't specify the isolation, neither does JBoss.
It uses whatever is defined by the driver/database.

This is all explained in the documentation.

> BMP entitybeans cause db-deadlocks
> ----------------------------------
>
>                 Key: JBAS-3679
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3679
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: windows 2003, sun jvm 1.4.2_06, INet Opta JDBC driver 6.04, SQLSERVER 2000
>            Reporter: Onno de Groote
>
> when using local-tx datasources with no transactionisolation-level specified, it looks like jboss sets it to repeatable-read or higher. The problem with this situation is that in high concurrency situations, two threads using the same entity-bean ( with or without same primary-key ) cause deadlocks in SQLServer. The reason for this is that de select queries in the findby and ejbload code set S-locks on the indexes in the database, thereby blocking any update query of a different thread. In the situation that thread-1 first performs the findby and ejbload, causing S-locks, after which thread-2 does the same, after which thread-1 tries ejbstore, which blocks because of the S-locks of thread-2. Then thread-2 tries the ejbstore, which in turn is blocked by the S-locks of thread-1. SQLServer detectes a deadlock and selects a deadlock victim and one transaction fails. In this case there should not have been a problem so the transaction-failure is incorrect and only caused by the wrong transactionisolation level

-- 
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

       



From jira-events at jboss.com  Fri Sep 22 05:49:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 05:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22428953.1158918541184.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3685?page=all ]

Adrian Brock updated JBAS-3685:
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
         Assignee: Kabir Khan

There's no point creating a critical issue if you don't assign it
to a "fix version". :-)

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:55:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Fri, 22 Sep 2006 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-358) Adding
 core.FacesMessages requires JSF libraries to compile component
Message-ID: <21739116.1158918901085.JavaMail.jira@cloud.prod.atl2.jboss.com>

Adding core.FacesMessages requires JSF libraries to compile component
---------------------------------------------------------------------

                 Key: JBSEAM-358
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-358
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


I have this in a Seam component:

    // For error messages
    @In(create=true)
    private FacesMessages facesMessages;


This is org.jboss.seam.core.FacesMessages. It doesn't extend anything from JSF but I still can't compile my Seam component without the JSF stubs on the classpath:

/Users/turin/work/local/lab8/modules/beans/src/auction/beans/PlaceBidImpl.java
    Error:Error:line (112)cannot access javax.faces.application.FacesMessage
file javax/faces/application/FacesMessage.class not found

This is inconvenient because this is the only JSF compile-time dependency in all of my Seam components and I have to add the JSF libs to my compile classpath just for this. I don't really know why this is required... because of the static methods in FacesMessages?

In any case, it would be nice to be able to send JSF messages without binding the component to JSF and I initially thought that this was the usecase for core.FacesMessages in Seam.



-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:58:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 05:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-325) Priority traffic
 should use separate network
Message-ID: <8147630.1158919081452.JavaMail.jira@cloud.prod.atl2.jboss.com>

Priority traffic should use separate network
--------------------------------------------

                 Key: JGRP-325
                 URL: http://jira.jboss.com/jira/browse/JGRP-325
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.x


Priority traffic, e.g. heartbeats from FD, or JOIN/LEAVE requests should use a separate NIC, possibly connected to a separate network. This would ensure that priority traffic is *not* discarded because of regular replication traffic which clogs the line

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:04:02 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 06:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12937529.1158919442484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=all ]

Carlo de Wolf updated EJBTHREE-712:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=91149

> Support EJBContext injection through ejb-jar.xml
> ------------------------------------------------
>
>                 Key: EJBTHREE-712
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC10 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>
> Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:13:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 06:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10281588.1158919981107.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3685?page=comments#action_12343804 ] 
            
Kevin Conner commented on JBAS-3685:
------------------------------------

Apologies.  I created it as critical because I was under the impression that I was supposed to for the 4.0.5 release.

I still have to chase it up with Dimitris.

I promise the next one will have a "fix version" ;-)


> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:16:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5776157.1158920161518.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=comments#action_12343805 ] 
            
Carlo de Wolf commented on EJBTHREE-712:
----------------------------------------

EJB3 core 16.15 paragraph 2

> Support EJBContext injection through ejb-jar.xml
> ------------------------------------------------
>
>                 Key: EJBTHREE-712
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:16:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9639442.1158920161714.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=all ]

Carlo de Wolf updated EJBTHREE-712:
-----------------------------------

        Fix Version/s: EJB 3.0 RC10 - FD
    Affects Version/s: EJB 3.0 RC9 - FD
                           (was: EJB 3.0 RC10 - FD)

> Support EJBContext injection through ejb-jar.xml
> ------------------------------------------------
>
>                 Key: EJBTHREE-712
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:22:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 06:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3684) References to
	TxManager
In-Reply-To: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17022654.1158920521351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3684?page=all ]

Dimitris Andreadis updated JBAS-3684:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3684
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.
>       ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
>       ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java
> These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:28:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
Message-ID: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>

Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-3686
                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Galder Zamarreno
         Assigned To: Dimitris Andreadis


A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
(notice missing / at the end):

      <attribute name="URLs">
         deploy
      </attribute>

leads to the datasource not deploying due to waiting on:

2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'

JBoss deploys this instead:

2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'

The bug is that DefaultDS is an incomplete deployment and the 
URLDeploymentScanner should throw something like this:

17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:28:01 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Fri, 22 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-61) Apache Tomcat 6.0
In-Reply-To: <21194316.1153309331365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4623818.1158920881560.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-61?page=comments#action_12343806 ] 
            
Remy Maucherat commented on JBWEB-61:
-------------------------------------

It should be done now, and all the necessary refinements and accessory components are implemented.

Remaining:
- Docs for Comet API

> Apache Tomcat 6.0
> -----------------
>
>                 Key: JBWEB-61
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-61
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Remy Maucherat
>         Assigned To: Remy Maucherat
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:40:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 06:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25462935.1158921601446.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343807 ] 
            
Dimitris Andreadis commented on JBAS-3686:
------------------------------------------

Not sure if this is a bug. If you omit the slash (deploy/) it will treat the deploy dir not as a directory to scan, but as a package with subdeployment, and then all strange things start to happen.

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:43:01 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Fri, 22 Sep 2006 06:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3674) service
 MetricsLookup dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26421829.1158921781761.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3674?page=comments#action_12343808 ] 
            
abo abo commented on JBAS-3674:
-------------------------------

i can't find any way to see _all_ invocations or called methods on a server.
this feature is fery useful to identify problems and should be re-introduced even if you can monitor specific mbeans through web-console.

any reason to drop this feature?


> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:43:01 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Fri, 22 Sep 2006 06:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3674) service
 MetricsLookup dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20948108.1158921782065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3674?page=all ]

abo abo reopened JBAS-3674:
---------------------------

             

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:46:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 06:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31839915.1158921961367.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343809 ] 
            
Galder Zamarreno commented on JBAS-3686:
----------------------------------------

But it leads to an attempt to deploy a *-ds.xml as if it were
a sub deployment of deploy. If it attempts to deploy it and 
it can't it should say something, otherwise, don't even 
start the deployment.

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:52:01 2006
From: jira-events at jboss.com (J-C jc (JIRA))
Date: Fri, 22 Sep 2006 06:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18691548.1158922321892.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343810 ] 
            
J-C jc commented on EJBTHREE-649:
---------------------------------

Just another comment about flush. To be able to implement features such as an audit trail it will be nice to have a public API to know wich objects has been created/modified/deleted in the current transaction and another to know which properties have been changed.
It looks that these informations are the same as the one used for the flush.

This kind of API wil probably be much more efficient than the audit trail on hibernate  Wiki. It is not relevant to that bug, but as it is in the same area ... It will really help (this subject had been discussed on hibernate and EJB3 forums few months ago)  



> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 07:22:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 07:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-326) Run testsuite by
 default with udp.xml, tcp.xml and tcp-nio.xml
Message-ID: <30322123.1158924121306.JavaMail.jira@cloud.prod.atl2.jboss.com>

Run testsuite by default with udp.xml, tcp.xml and tcp-nio.xml
--------------------------------------------------------------

                 Key: JGRP-326
                 URL: http://jira.jboss.com/jira/browse/JGRP-326
             Project: JGroups
          Issue Type: Task
    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

        


From jira-events at jboss.com  Fri Sep 22 07:22:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 07:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-321)
 CloseTest.testShutdown() fails with -Dconfig=tcp.xml
In-Reply-To: <20644013.1158350917305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18522067.1158924121458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-321?page=all ]

Bela Ban updated JGRP-321:
--------------------------

    Fix Version/s: 2.5
                       (was: 2.4)

> CloseTest.testShutdown() fails with -Dconfig=tcp.xml
> ----------------------------------------------------
>
>                 Key: JGRP-321
>                 URL: http://jira.jboss.com/jira/browse/JGRP-321
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            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

        


From jira-events at jboss.com  Fri Sep 22 07:28:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Fri, 22 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24598479.1158924481252.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-98?page=comments#action_12343811 ] 
            
Jonathan Halliday commented on JBTM-98:
---------------------------------------


The  test case is based on the Oracle sample code from e.g. http://download-uk.oracle.com/docs/cd/A87860_01/doc/java.817/a83724/samapp9.htm#1012235  Using this code as a starting point, you can alter the size of the byte arrays used in the Xid. The test continues to pass even with arrays shorter than 64 bytes.  This would tend to indicate the problem lies elsewhere. If you have an alternative test case that contradicts this, please submit it. It's possible the problem you are seeing is elsewhere in the code and is masked or avoided as a result of altering the array sizes.

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 07:36:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 07:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14985650.1158924961232.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343813 ] 
            
Dimitris Andreadis commented on JBAS-3686:
------------------------------------------

Again, I don't think it is a scanner problem, because in this case it doesn't scan at all the deploy dir. It just passes the url to the MainDeployer which deployes this as a JAR deployment and then it reports the result.

If better error reporting could be done at some point, let me know. 

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 07:48:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 07:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11443311.1158925681254.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343814 ] 
            
Adrian Brock commented on JBAS-3686:
------------------------------------

The issue is caused by the following code in MainDeployer:deploy(URL)

      if( sdi.state != DeploymentState.STARTED )
         checkIncompleteDeployments();

In this case, the top level deployment is started (the deploy folder)
so no check is made.

Since there are no other deployments, it never does this code in URLDeploymentScanner:

      // Validate that there are still incomplete deployments
      if (lastIncompleteDeploymentException != null)
      {
         try
         {
            Object[] args = {};
            String[] sig = {};
            getServer().invoke(getDeployer(),
                               "checkIncompleteDeployments", args, sig);
         }
         catch (Exception e)
         {
            Throwable t = JMXExceptionDecoder.decode(e);
            log.error(t);
         }
      }

This just looks broken to me. In this case, there is nothing wrong with the deployment,
the issue is with the MBeans created as part of the deployment process not having
dependencies satisfied.

In my opinion, the MainDeployer should not be automatically
doing any checks for incomplete deployments it should be invoked by the caller
since only it knows whether there are multiple urls that could have some relation.

main.deploy(url1); // creates mbean1
main.deploy(url2); // creates mbean2 that depends on mbean1
main.checkIncompleteDeployments();

In this way, the URLDeploymentScanner should always check for incompleteness
after every scan that deploys or undeploys something.

You could have a helper method in MainDeployer for simple cases,
which is also what should be used by the testsuite (in most cases).

e.g.
MainDeployer::deployAndCheck(URL url)
{
   deploy(url);
   checkIncompleteDeployments();
}

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 08:09:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 08:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-323) Set shunning to
 false in both FD and GMS
In-Reply-To: <15586805.1158610675069.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10846740.1158926941205.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-323?page=all ]

Bela Ban resolved JGRP-323.
---------------------------

    Resolution: Done

> Set shunning to false in both FD and GMS
> ----------------------------------------
>
>                 Key: JGRP-323
>                 URL: http://jira.jboss.com/jira/browse/JGRP-323
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Optional
>             Fix For: 2.4
>
>
> should be the default, even if no value is set

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:02:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 22 Sep 2006 09:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-144) Add unit tests for
 new EPR and messaging classes.
In-Reply-To: <3775013.1158753481061.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3821076.1158930121320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-144?page=all ]

Mark Little closed JBESB-144.
-----------------------------

    Resolution: Done

> Add unit tests for new EPR and messaging classes.
> -------------------------------------------------
>
>                 Key: JBESB-144
>                 URL: http://jira.jboss.com/jira/browse/JBESB-144
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 3 days
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-315) Create check list
 of manual tests
In-Reply-To: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24999370.1158930301473.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-315?page=comments#action_12343818 ] 
            
Bela Ban commented on JGRP-315:
-------------------------------

The list is at JGroups/doc/tests/ManualTests.txt

> Create check list of manual tests
> ---------------------------------
>
>                 Key: JGRP-315
>                 URL: http://jira.jboss.com/jira/browse/JGRP-315
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
> - JGroups/doc/tests/GmsTests.txt
> - Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-315) Create check list of
	manual tests
In-Reply-To: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27673704.1158930301608.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-315?page=all ]

Bela Ban updated JGRP-315:
--------------------------

        Fix Version/s: 2.4
                           (was: 2.5)
    Affects Version/s: 2.3 SP1
                           (was: 2.4)

> Create check list of manual tests
> ---------------------------------
>
>                 Key: JGRP-315
>                 URL: http://jira.jboss.com/jira/browse/JGRP-315
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
> - JGroups/doc/tests/GmsTests.txt
> - Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-315) Create check list of
	manual tests
In-Reply-To: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21390877.1158930301734.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-315?page=all ]

Bela Ban resolved JGRP-315.
---------------------------

    Resolution: Done

> Create check list of manual tests
> ---------------------------------
>
>                 Key: JGRP-315
>                 URL: http://jira.jboss.com/jira/browse/JGRP-315
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
> - JGroups/doc/tests/GmsTests.txt
> - Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-322) Provide 3 major
 default configurations (udp.xml, tcp.xml and tcp-nio.xml)
In-Reply-To: <7218240.1158479447973.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18336529.1158930301883.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-322?page=all ]

Bela Ban resolved JGRP-322.
---------------------------

    Resolution: Done

> Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)
> -------------------------------------------------------------------------
>
>                 Key: JGRP-322
>                 URL: http://jira.jboss.com/jira/browse/JGRP-322
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> Those configs should be the same in stacks.xml (for the Multiplexer) as well

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:11:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-327) Certify JGroups 2.2.9
 SP4 with JBossAS 4.0.3 and 4.0.4
Message-ID: <21738393.1158930661117.JavaMail.jira@cloud.prod.atl2.jboss.com>

Certify JGroups 2.2.9 SP4 with JBossAS 4.0.3 and 4.0.4
------------------------------------------------------

                 Key: JGRP-327
                 URL: http://jira.jboss.com/jira/browse/JGRP-327
             Project: JGroups
          Issue Type: Support Patch
    Affects Versions: 2.2.9 SP4
            Reporter: Bela Ban
         Assigned To: Bela Ban
         Attachments: jgroups-all.jar



-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:11:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-327) Certify JGroups 2.2.9
 SP4 with JBossAS 4.0.3 and 4.0.4
In-Reply-To: <21738393.1158930661117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2672685.1158930661234.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-327?page=all ]

Bela Ban updated JGRP-327:
--------------------------

    Attachment: jgroups-all.jar

> Certify JGroups 2.2.9 SP4 with JBossAS 4.0.3 and 4.0.4
> ------------------------------------------------------
>
>                 Key: JGRP-327
>                 URL: http://jira.jboss.com/jira/browse/JGRP-327
>             Project: JGroups
>          Issue Type: Support Patch
>    Affects Versions: 2.2.9 SP4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>         Attachments: jgroups-all.jar
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:11:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Fri, 22 Sep 2006 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-714) Session objects
 returned by
 injection should implement SessionImplementor in addition to
 o.h.classic.Session
Message-ID: <15947693.1158930661367.JavaMail.jira@cloud.prod.atl2.jboss.com>

Session objects returned by injection should implement SessionImplementor in addition to o.h.classic.Session
------------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-714
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-714
             Project: EJB 3.0
          Issue Type: Bug
          Components: EJB3 Extensions
    Affects Versions: EJB 3.0 RC9 - FD
            Reporter: Emmanuel Bernard
            Priority: Minor


Hibernate internally can cast a session object to
org.hibernate.classic.Session (subinterface of org.hibernate.Session)
org.hibernate.engine.SessionImplementor

This is especially useful when using the DetachedCriteria API

So at least org.jboss.ejb3.entity.TransactionScopedHibernateSession should implement it

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:31:00 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-328)
 MultiplexerTest.testStateTransferWithReconnect() has leftover threads if
 run with -Dstack=tcp
Message-ID: <33065949.1158931860965.JavaMail.jira@cloud.prod.atl2.jboss.com>

MultiplexerTest.testStateTransferWithReconnect() has leftover threads if run with -Dstack=tcp
---------------------------------------------------------------------------------------------

                 Key: JGRP-328
                 URL: http://jira.jboss.com/jira/browse/JGRP-328
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:31:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Fri, 22 Sep 2006 09:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20575377.1158931861559.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343822 ] 
            
Emmanuel Bernard commented on EJBTHREE-649:
-------------------------------------------

Interceptor do what you want (onFlushDirty)

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:39:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-328)
 MultiplexerTest.testStateTransferWithReconnect() has leftover threads if
 run with -Dstack=tcp
In-Reply-To: <33065949.1158931860965.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13603075.1158932341075.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-328?page=all ]

Bela Ban updated JGRP-328:
--------------------------

        Fix Version/s: 2.5
                           (was: 2.4)
    Affects Version/s: 2.4
                           (was: 2.3 SP1)

> MultiplexerTest.testStateTransferWithReconnect() has leftover threads if run with -Dstack=tcp
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-328
>                 URL: http://jira.jboss.com/jira/browse/JGRP-328
>             Project: JGroups
>          Issue Type: Bug
>    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

        


From jira-events at jboss.com  Fri Sep 22 09:42:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 09:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-777) FileCacheLoader
 can return null
 for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
Message-ID: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>

FileCacheLoader can return null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
------------------------------------------------------------------------------------------------------

                 Key: JBCACHE-777
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
            Reporter: Galder Zamarreno
         Assigned To: Manik Surtani
            Priority: Minor


FileCacheLoader can return a null value for get(fqn) which goes against the JavaDoc 
requirements for that method:

 /**
    * Returns all keys and values from the persistent store, given a fully qualified name.
    *
    * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
    * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
    * implementations should be checked for compliance with the behaviour expected.
    *
    * @param name
    * @return Map<Object,Object> keys and values for the given node. Returns
    * null if the node is not found.  If the node is found but has no
    * attributes, this method returns an empty Map.
    * @throws Exception
 */

If a get(fqn) operation occurrs before a put and the node (directory) does not exist, FCL returns 
null when it should return an empty Map.

If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
following misleading warning message is logged:

10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:49:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Fri, 22 Sep 2006 09:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
Message-ID: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>

warning with TransactionManager interface in JTS with external TM
-----------------------------------------------------------------

                 Key: JBTM-128
                 URL: http://jira.jboss.com/jira/browse/JBTM-128
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
            Reporter: Jonathan Halliday
         Assigned To: Mark Little


When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:

2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
java.lang.NullPointerException
        at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
        at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)

This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.

Test code to reproduce warning:
        System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
        System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
        ORB myORB = ORB.getInstance("ServerSide");
        OA myOA = OA.getRootOA(myORB);
        myORB.initORB(args, null);
        myOA.initOA();
        javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
        transactionManager.begin();
        transactionManager.commit();


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1338) Thread Pool
 improvements on the client
Message-ID: <7974366.1158933121618.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1338?page=all ]

Adrian Brock closed JBAS-1338.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Thread Pool improvements on the client
> --------------------------------------
>
>                 Key: JBAS-1338
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1338
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> The thread usage on the client needs to be improved.
> The users of threads are:
> 1) The invocation layers for message delivery
> 2) The message listeners to wait for messages
> These should be combinded to use a single thread pool.
> There is no need for a message listener to hold a thread while it is waiting for a message.
> It can add itself to a registry which is then used by delivery to invoke the correct listener
> when a message arrives.
> In fact, by spec the listeners should register themselves with the session and the session
> deliver the messages (single threadedly - is that a word? :-).

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1339) Persistence Manager
	Improvements
Message-ID: <27806050.1158933121762.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1339?page=all ]

Adrian Brock closed JBAS-1339.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Persistence Manager Improvements
> --------------------------------
>
>                 Key: JBAS-1339
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1339
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> There are a number of improvements that can be made to the persistence manager.
> This should really be done by writing a new version that can then be optionally used while
> it is experimental.
> 1) Make use of the datasource mappings - similar what has been done for the EJB timer
> 2) The use of the JTA transaction is unnecessary since we are the only one in the transaction branch. The tranaction still needs suspending so we are isolated from any wrapping transacton.
> 3) Make use of build writes to the database
> This can be used for transactional sessions where multiple messages are processed
> But it could also be used where people want to relax the absolute requirement that
> messages are persisted in return for some performance improvement.
> 4) A general review/rewrite of where the persistence manager is invoked from the
> server with an aim to improve performance.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1340) Lazily Loading Queues
Message-ID: <20625884.1158933121970.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1340?page=all ]

Adrian Brock closed JBAS-1340.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Lazily Loading Queues
> ---------------------
>
>                 Key: JBAS-1340
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1340
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> This is a major change that is the last obstacle to JBossMQ scalability.
> The idea is that messages will only be loaded into the server when the destination is activated
> and then only part of the messages are loaded (enough to deal with the current throughput).
> An attempt was made to do this and committed on Branch JBoss_3_2_5_JBossMQ_Lazy but the
> work was abandoned. It does not deal with the more difficult problems.
> In any case, the BasicQueues should be talking directly with the PersistenceManager.
> In fact, I would favour that the BasicQueue implementation is actually pluggable and
> determined by the PM to allow better optimization between these two important layers.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1337) Thread Pool
 improvements on the server
Message-ID: <1445350.1158933122272.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1337?page=all ]

Adrian Brock closed JBAS-1337.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Thread Pool improvements on the server
> --------------------------------------
>
>                 Key: JBAS-1337
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1337
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> There are a number of different components on the server that use thread pools.
> 1) Invocation Layers
> 2) Client Consumer for delivering messages
> 3) Scheduled delivery/message expiration
> These need to be combined to share threads and minimize context switching where possible.
> The thread pool should be based on the BasicThreadPool from jboss-common

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1343) ReadAhead and DUPS_OK
 message acknowledgement
Message-ID: <25982339.1158933122558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1343?page=all ]

Adrian Brock closed JBAS-1343.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> ReadAhead and DUPS_OK message acknowledgement
> ---------------------------------------------
>
>                 Key: JBAS-1343
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1343
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> Performance can be improved by sending mulitple messages in one request to the client
> when they are using a MessageListener.
> Similary, there is no implementation of DUPS_OK message acknowledgement, which would
> reduce the number of network requests required to acknowledge receipt of messages.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1585) Enhance Queue
	throughput
Message-ID: <12788238.1158933301658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1585?page=all ]

Adrian Brock closed JBAS-1585.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Enhance Queue throughput
> ------------------------
>
>                 Key: JBAS-1585
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1585
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Ivelin Ivanov
>
> > -----Original Message-----
> > From: Adrian Brock
> > Sent: Monday, March 14, 2005 2:35 PM
> > To: Ivelin Ivanov
> > Cc: Stan Silvert; Neal Byrd; The Core; Rebecca Goldstein
> > Subject: RE: JMS Reference
> > 
> ...
> > I know you can get about x8 improvement in JBossMQ just by adding
> > some simple flow control.
> > 
> > Instead of doing the "one in, one out" policy on the message cache
> > when memory is tight (i.e. move some old messages to disk to make
> > room for the new messages)
> > I did a simple test instead  with
> > Thread.sleep(1000);
> > to slow down the senders and let the receivers clear some memory.
> > 
> > The message throughput went from 1 million messages/hour to 8 million.
> > I did this test around JBoss-3.0.7 time when the performance was
> > very poor.
> > 
> > I discarded the idea as too simplistic since the mechanism
> > requires blocking server threads. But it does show JBossMQ
> > could easily be improved if we had the motivation/resources
> > to work on the performance without degrading its reliability.
> >

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2444) Keeping Ordering
 after message NACK
Message-ID: <3463139.1158933301865.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2444?page=all ]

Adrian Brock closed JBAS-2444.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Keeping Ordering after message NACK
> -----------------------------------
>
>                 Key: JBAS-2444
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2444
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>
> There is a common FAQ about how to keep message ordering in the event of failure (i.e. a NACK or transaction rollback).
> JMS gives no such guarantees.
> However, we could give that guarantee at the expense of throughput.
> Basically what we need to do is not allow anybody to receive() a message until the single message (or group of messages
> in the same transaction) that has already been received is either nacked or acked.
> Once the nack (rollback) comes from the client that has the "checked out" message it will be reinserted back into the Queue
> at the top of the list and then we allow the next receive() to run. 
> Meaning it always the nacked message and can't get any other message until the top message is acked.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2492) Add an
 removeReceiver() to the receive(long timeout) processing
Message-ID: <3156424.1158933302002.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2492?page=all ]

Adrian Brock closed JBAS-2492.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Add an removeReceiver() to the receive(long timeout) processing
> ---------------------------------------------------------------
>
>                 Key: JBAS-2492
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2492
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>
> Currently if the receive(long) times out, the receiver is left as waiting for a message on the server.
> This doesn't cause any semantic problems, but it can lead to an unnecessary
> deliver/nack lifecyle if there is no subsequent receive() request and the receiver is not closed.
> It would be better to have the option for receive(long) to issue an removeReceiver
> when it stops waiting.
> However, this requires an incompatible change to the IL - there is currently no such method in the interface.
> It would also need to be implementated carefully to avoid a race condition with
> connection.start/stop().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1333) connectionFailure
Message-ID: <19481376.1158933302432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1333?page=all ]

Adrian Brock closed JBAS-1333.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> connectionFailure
> -----------------
>
>                 Key: JBAS-1333
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1333
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Adrian Brock
>
> The connectionFailure invocation from the IL layer needs to pass through the interceptor
> rather than just invoking on the destination manager.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2583) Potential for runaway
 allocation of Connection objects
Message-ID: <26040635.1158933482057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ]

Adrian Brock closed JBAS-2583.
------------------------------

    Resolution: Done

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Potential for runaway allocation of Connection objects
> ------------------------------------------------------
>
>                 Key: JBAS-2583
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2583
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Natalia Kowalczyk
>
> org.jboss.mq.Connection class uses a singleton  EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. 
> Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-2583) Potential for
 runaway allocation of Connection objects
Message-ID: <1208889.1158933482216.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ]

Adrian Brock reopened JBAS-2583:
--------------------------------

             

> Potential for runaway allocation of Connection objects
> ------------------------------------------------------
>
>                 Key: JBAS-2583
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2583
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Natalia Kowalczyk
>
> org.jboss.mq.Connection class uses a singleton  EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. 
> Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2583) Potential for runaway
 allocation of Connection objects
Message-ID: <19697332.1158933482445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ]

Adrian Brock closed JBAS-2583.
------------------------------

    Resolution: Deferred

> Potential for runaway allocation of Connection objects
> ------------------------------------------------------
>
>                 Key: JBAS-2583
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2583
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Natalia Kowalczyk
>
> org.jboss.mq.Connection class uses a singleton  EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. 
> Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2464) Support JMSX
	properties
Message-ID: <24885789.1158933482630.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2464?page=all ]

Adrian Brock closed JBAS-2464.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Support JMSX properties
> -----------------------
>
>                 Key: JBAS-2464
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2464
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Look at supporting other JMSX properties in JBossMQ

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13235554.1158933482829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3685?page=all ]

Kabir Khan resolved JBAS-3685.
------------------------------

    Resolution: Done

org.jboss.tm.TxManager is needed when running in older versions of JBoss. I have hidden the details in TxManagerTimeoutReader if running in an old version of JBoss. If TransactionTimeoutConfiguration is available, the new mechanism is used via the TransactionTimeoutConfigurationReader.

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:03 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1342) Message Serialization
Message-ID: <19069242.1158933483177.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1342?page=all ]

Adrian Brock closed JBAS-1342.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Message Serialization
> ---------------------
>
>                 Key: JBAS-1342
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1342
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: JBAS-1342-SpyTextMessage.zip
>
>
> The message body does not need to be deserialized on the server.
> It could just be retained as byte[]
> This will avoid unnecessary Object serialiation at the transport and persistent layer
> inside the server.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:01:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1345) Clustered Invocation
	Layer
Message-ID: <849376.1158933662723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1345?page=all ]

Adrian Brock closed JBAS-1345.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Clustered Invocation Layer
> --------------------------
>
>                 Key: JBAS-1345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Clustered Invocation Layer
> 1) Transportation of the cluster view to the client.
> 2) Persistent connections that allows the server to recover the client's state after a failure.
> Both these together will mean the client can transparently failover after a server failure.
> The persistent connections could be used without clustering where the client waits for server recovery.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1348) Message Selector
	Performance
Message-ID: <11684304.1158933841413.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1348?page=all ]

Adrian Brock closed JBAS-1348.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Message Selector Performance
> ----------------------------
>
>                 Key: JBAS-1348
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1348
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Improving Message Selector Performance
> It is a common anti-pattern for users to set up a contested queue
> where multiple receivers try to take messages based on a message selector.
> In most circumstances a Topic is what they should be using.
> But there is a circumstance where a Topic does not work as required,
> that is when a message matches many of the receiver's selector but you
> only want one receiver to process the message (it doesn't matter which).
> The problem is that when a receiver does not match a message towards
> the top of a large Queue (or none at all). The operation to find a message
> or discover there are no messages is very expensive. It is read and skip.
> This can be even worse when the bottom of the queue has been moved out
> to disk by the MessageCache.
> The solution is to provide "an index" over a particular property,
> e.g.
> <mbean code="org.jboss.mq.server.jmx.Queue"
> 	 name="jboss.mq.destination:service=Queue,name=A">
>     <optimized-selector>JMSMessageID</optimized-selector>
>     <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
> </mbean>
> This configuration should be passed via the BasicQueueParameters to the BasicQueue.
> NOTE: This is irrevelent for Topics. Topics run their selector before the message is added
> to the subscription, anything not matching the selector is dropped.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1300) Non-Remote JMS HA
Message-ID: <14139178.1158933841678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1300?page=all ]

Adrian Brock closed JBAS-1300.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Non-Remote JMS HA
> -----------------
>
>                 Key: JBAS-1300
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1300
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
>            Reporter: Andrew Oliver
>            Priority: Minor
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> It should be possible to use JMS on all servers in a cluster with HA enabled.  Meaning:
> 1. Database as a store.  Everyone node uses shared DB.
> 2. JMS_MESSAGES table includes node name
> 3. In the event of group membership changes another node picks up the old node's messages
> 4. JMS Client proxy autofails to another node

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1891) Allow chunking of
 message during recovery
Message-ID: <32784474.1158933842190.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1891?page=all ]

Adrian Brock closed JBAS-1891.
------------------------------

    Fix Version/s: JBossAS-4.0.4.GA
       Resolution: Done

This was already done in 4.0.4,
see RecoveryMessagesChunk here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQJDBC2Persistence

> Allow chunking of message during recovery
> -----------------------------------------
>
>                 Key: JBAS-1891
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1891
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.1 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.4.GA
>
>
> Allow messages to be loaded in "chunks" during the recovery process.
> Need to discuss/understand how this can be done where it requires vendor specific processing,
> e.g. see the top level problem for the MySQL issue.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1349) Message Bridge
Message-ID: <33512335.1158933841538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1349?page=all ]

Adrian Brock closed JBAS-1349.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Message Bridge
> --------------
>
>                 Key: JBAS-1349
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1349
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Implementation of a MessageBridge.
> ----------------------------------
> This is a proxy that allows messages to be sent to one JMS server
> and then forwarded to the real destination.
> To the senders this looks like a plain queue or topic.
> This is the simplist implementation, more performant implementations are possible:
> 1) Implement the bridge as a new destination type within JBossMQ
> 2) It will behave similarly to a Queue but will not accept external receivers.
> 3) On a background thread (inside a JTA transaction) 
> take some messages from the queue and send them to the real destination.
> 4) The background thread should automatically recover from a failed connection
> and retry at configurable intervals. Similarly it should keep retrying if
> the connection cannot be instantiated at initial startup.
> This is similar to what the MDB does.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2120) JBossMQ should use the
 <type-mapping> from the DataSource
Message-ID: <24079609.1158934021375.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2120?page=all ]

Adrian Brock closed JBAS-2120.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> JBossMQ should use the <type-mapping> from the DataSource
> ---------------------------------------------------------
>
>                 Key: JBAS-2120
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2120
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC1
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Currently JBossMQ's 
> JDBC2 persistence manager (http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQJDBC2Persistence)
> JDBC statemanager (http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQStateJDBC)
> have their SQL configured through a big map of system properties.
> This means that you need different configurations for each backend DB.
> See docs/examples/jms or http://www.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB
> Instead, we should use the <type-mapping> from the DataSource which uses the standardjbosscmp-jdbc.xml
> to map queries to the database.
> The only configuration required, would then be
> * The DataSource
> * Table Names
> * Column Names
> with default names for each.
> This should be done as a "fork", e.g. create a JDBC4 
> since we still want to support people with the old configurations.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3035) Can't proxy JMS
 Queues with org.springframework.jndi.JndiObjectFactoryBean
Message-ID: <25126133.1158934021777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3035?page=all ]

Adrian Brock closed JBAS-3035.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Can't proxy JMS Queues with org.springframework.jndi.JndiObjectFactoryBean
> --------------------------------------------------------------------------
>
>                 Key: JBAS-3035
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3035
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1
>         Environment: SpringFramework 1.2.7
>            Reporter: Marian Noga
>            Priority: Minor
>
> Proxying of mq destinations is impossible because of lack of Interface for SpyDestination.class
> Even proxying with CGLib won't work because SpyDestination.class has no public constructor.
> Following configuration:
> <bean id="deadLetterQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
> <property name="jndiName" value="queue/DLQ" />
> <property name="cache" value="false" />
> <property name="proxyInterface" value="javax.jms.Queue" />
> </bean>	
> produces output:
> org.springframework.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ; nested exception is javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ; nested exception is javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ
> javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ
> at org.jboss.mq.SpyMessageProducer.send(SpyMessageProducer.java:225)
> at org.jboss.mq.SpyMessageProducer.send(SpyMessageProducer.java:212)
> at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:519)
> at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:504)
> at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479)
> at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:432)
> at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477)
> at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> changing proxyInterface to: javax.jms.Destination
> Code:
> <bean id="responseQueue" class="org.springframework.jndi.JndiObjectFactoryBean" lazy-init="false">
> <property name="jndiName" value="queue/konektor_out" />
> <property name="cache" value="false" />
> <property name="proxyInterface" value="javax.jms.Destination" />
> </bean>	
> produces following output:
> java.lang.ClassCastException: $Proxy1
> at org.jboss.mq.SpySession.createProducer(SpySession.java:657)
> at org.springframework.jms.core.JmsTemplate.doCreateProducer(JmsTemplate.java:807)
> at org.springframework.jms.core.JmsTemplate.createProducer(JmsTemplate.java:788)
> at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:498)
> at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479)
> at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:432)
> at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477)
> at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543)
> can anyone tell is it possible to change behaviour of this code:
> SpyMessageProducer.class
> if (destination == null || (destination instanceof SpyDestination) == false)
>          throw new InvalidDestinationException("Destination is not an instance of SpyDestination " + destination); 	
> if SpyDestination was an interface in the code above, everything would be fine.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1347) Improved management
Message-ID: <3179707.1158934021894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1347?page=all ]

Adrian Brock closed JBAS-1347.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Improved management
> -------------------
>
>                 Key: JBAS-1347
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1347
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> There are a number of areas in JBossMQ that could be better exposed for management.
> The main one is the ClientConsumers.
> This would allow an admin to break a connection with a client and also see stats at the client level.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1346) JDBC StateManager
Message-ID: <26190183.1158934022379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1346?page=all ]

Adrian Brock closed JBAS-1346.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> JDBC StateManager
> -----------------
>
>                 Key: JBAS-1346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1346
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> The JDBC StateManager should have operations to create/delete users and subscriptions in the
> database, just like the old File StateManager did.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:02 2006
From: jira-events at jboss.com (Johnny Healey (JIRA))
Date: Fri, 22 Sep 2006 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1054) Invalid HTML in
	divRenderer
Message-ID: <31885108.1158934022590.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invalid HTML in divRenderer
---------------------------

                 Key: JBPORTAL-1054
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1054
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.4 Final
         Environment: CentOS release 4.4 (Final), jdk1.5.0_06
            Reporter: Johnny Healey
         Assigned To: Julien Viet


Minimize/Maximize buttons have urls containing unescaped ampersands.

"&windowstate=minimized" should read "&amp;windowstate=minimized"

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3377) Multiple JMS
 subscriber performance in same VM
Message-ID: <10669113.1158934022809.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3377?page=all ]

Adrian Brock closed JBAS-3377.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Multiple JMS subscriber performance in same VM
> ----------------------------------------------
>
>                 Key: JBAS-3377
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3377
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: floe fliep
>            Priority: Optional
>
> Consider the following JMS publish/subscribe setup in JB AS 4.0.4GA:
> - one JMS topic publisher running in the AS VM
> - several JMS subscribers to the same topic, running on several threads in one client VM, sharing a single TopicConnection
> While debugging through the JBoss AS 4.0.4GA code, it seems, and as far I was able to see, that the AS sends for each message sent through the TopicPublisher.publish(msg) several identical instances of org.jboss.mq.ReceiveRequest over the network connection, i.e. as many instances as we have subscriptions on the client side. This induces considerable network overhead with larger messages any many clients.
> One workaround to it is to make a client-side construction where there is only subscriber consuming messages, which in its turn distributes them locally. But this feels a bit like building your own JMS.
> Would there be a way to improve this or is this related to constraints imposed by the JMS spec.?

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:10:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 22 Sep 2006 10:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1053) WSRP URLs are
 improperly un-escaped in situations where they should be.
In-Reply-To: <4032852.1158880021204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5363944.1158934201179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1053?page=all ]

Chris Laprun resolved JBPORTAL-1053.
------------------------------------

    Resolution: Done

> WSRP URLs are improperly un-escaped in situations where they should be.
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1053
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1053
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:14:05 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-754) job scheduler
	persistence
Message-ID: <29801175.1158934445422.JavaMail.jira@cloud.prod.atl2.jboss.com>

job scheduler persistence
-------------------------

                 Key: JBPM-754
                 URL: http://jira.jboss.com/jira/browse/JBPM-754
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
            Priority: Critical
             Fix For: jBPM 3.2 alpha 2


some unexplainable hibernate problem while trying to lock jobs for execution:

16:08:22,843 [main] DEBUG GraphElement : event 'task-create' on 'Task(clean ceiling)' for 'Token(/)'
16:08:22,875 [main] DEBUG GraphElement : executing action 'CreateTimerAction(dc9766)'
16:08:22,875 [main] DEBUG GraphElement : event 'timer-create' on 'Task(clean ceiling)' for 'Token(/)'
16:08:22,875 [main] DEBUG GraphElement : event 'after-signal' on 'StartState(979f67)' for 'Token(/)'
16:08:22,875 [main] DEBUG Services : executing default save operations
16:08:22,875 [main] DEBUG HibernateSaveOperation : saving process instance
16:08:22,875 [main] DEBUG SaveLogsOperation : flushing logs to logging service.
16:08:22,890 [main] DEBUG CascadeSaveOperation : cascading save of 'org.jbpm.graph.exe.ProcessInstance at ffd135'
16:08:22,890 [main] DEBUG JbpmContext : closing JbpmContext
16:08:22,890 [main] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 6d2380
16:08:22,890 [main] DEBUG DbPersistenceService : committing hibernate transaction
16:08:22,890 [main] DEBUG DbPersistenceService : closing hibernate session
16:08:22,890 [main] DEBUG Services : closing service 'tx': org.jbpm.tx.TxService at 159780d
16:08:22,890 [main] DEBUG Services : closing service 'scheduler': org.jbpm.scheduler.db.DbSchedulerService at d8ca48
16:08:22,890 [main] DEBUG Services : closing service 'logging': org.jbpm.logging.db.DbLoggingService at c8570c
16:08:23,218 [main] DEBUG JobExecutor : starting thread group 'JbpmJobExector'...
16:08:23,218 [main] DEBUG JobExecutor : starting new job executor thread 'JbpmJobExector:192.168.1.100:1'
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG JbpmContext : creating JbpmContext
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG DbPersistenceServiceFactory : creating persistence service
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG DbPersistenceService : creating hibernate session
16:08:23,218 [main] DEBUG AbstractDbTestCase : going to sleep for 200 millis, waiting for the job executor to process more jobs
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG DbPersistenceService : beginning hibernate transaction
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG JobExecutorThread : querying for acquirable job...
16:08:23,375 [JbpmJobExector:192.168.1.100:1] DEBUG JobExecutorThread : trying to obtain a lock for 'timer(ceiling-timer,org.jbpm.taskmgmt.exe.TaskTimerExecutionDbTest$PlusPlus,16:08:22,875)'
16:08:23,406 [JbpmJobExector:192.168.1.100:1] ERROR AssertionFailure : an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: collection was not processed by flush(), role=org.jbpm.taskmgmt.def.Task.events
	at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:183)
	at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:328)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:125)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:54)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:16:04 2006
From: jira-events at jboss.com (Johnny Healey (JIRA))
Date: Fri, 22 Sep 2006 10:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1055)
 minimize/maximize causes portlet to return to initial state
Message-ID: <2682348.1158934564986.JavaMail.jira@cloud.prod.atl2.jboss.com>

minimize/maximize causes portlet to return to initial state
-----------------------------------------------------------

                 Key: JBPORTAL-1055
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1055
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Server
    Affects Versions: 2.4 Final
         Environment: CentOS release 4.4 (Final), jdk1.5.0_06
            Reporter: Johnny Healey
         Assigned To: Julien Viet


This has been noticed in a handful of custom portlets, but can be duplicated in the "event test" page that ships with the portal.  "Test Event A" can change the color of the text in "Test Event B", but minimizing or maximizing "Test Event B" causes the text to return to the original color, black.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 10:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21486061.1158934861130.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3685?page=comments#action_12343848 ] 
            
Kevin Conner commented on JBAS-3685:
------------------------------------

This is a better solution than the one I proposed but there is one flaw in it :-)

The TxTimeoutReaderFactory will only return the TransactionTimeoutConfigurationReader or NullTransactionTimeoutConfigurationReader and never returns the TxManagerTimeOutReader.

You may want to change this ;-)

Thanks for making the change so quickly.

Kev


> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:24:11 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 22 Sep 2006 10:24:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
In-Reply-To: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23534394.1158935051358.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-552?page=comments#action_12343849 ] 
            
Clebert Suconic commented on JBMESSAGING-552:
---------------------------------------------

I have executed org.jboss.test.messaging.jms.MessageConsumerTest::testRedeliveryToCompetingConsumerOnSubscription in loop and successfully executed. (5000 iterations). So.. at this point this is a can't reproduce bug status.

Maybe you some other idea to reproduce this.





> MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-552
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>         Attachments: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log, MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log
>
>
> Logs Attached

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:26:04 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-744) unify and improve the
 messaging and scheduler implementation
In-Reply-To: <11413941.1157122183945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22073665.1158935164306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-744?page=all ]

Tom Baeyens closed JBPM-744.
----------------------------

    Resolution: Done

new implementation is done.  

But there is one known critical problem with the new implementation still open: JBPM-754

> unify and improve the messaging and scheduler implementation
> ------------------------------------------------------------
>
>                 Key: JBPM-744
>                 URL: http://jira.jboss.com/jira/browse/JBPM-744
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 1
>
>
> * unify the scheduler and messaging implementation around the notion of a job
> * add support for multiple concurrent threads competing for job execution.  synchronization is to be done by acquiring locks.  acquiring the locks is done with optimistic locking so that it also works for hsqldb

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:26:04 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-617) keep the
 processdefinition.xml in the database
Message-ID: <32525203.1158935164442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-617?page=all ]

Tom Baeyens updated JBPM-617:
-----------------------------

    Fix Version/s: jBPM 3.2 alpha 2
                       (was: jBPM 3.2 alpha 1)

> keep the processdefinition.xml in the database
> ----------------------------------------------
>
>                 Key: JBPM-617
>                 URL: http://jira.jboss.com/jira/browse/JBPM-617
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions: jBPM 3.1, jBPM 3.2 alpha 1, jBPM 3.1.1,  jBPM 3.1.2
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2, jBPM 3.1.3
>
>
> the processdefinition.xml source should be added as a file when a process is deployed.
> this file filtering behaviour should be configurable.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:33:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter
 makes unnecessary temporary delete requests
Message-ID: <18185789.1158935581290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ]

Adrian Brock updated JBAS-1485:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> JMS ResourceAdapter makes unnecessary temporary delete requests
> ---------------------------------------------------------------
>
>                 Key: JBAS-1485
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1485
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1
>            Reporter: Adrian Brock
>            Priority: Optional
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The JMS ResourceAdaptor keeps track of temporaries created on a connection
> (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl)
> and deletes them.
> This is because we cannot expect the real JMS implementation to do this
> because the connection is pooled and not closed.
> However, if the user is deleting the temporaries themselves
> (good practice in terms of resource usage),
> the JMS ResourceAdapter does not know about this
> and tries to repeat the delete at connection.close();
> Solution:
> Add some wrapping processing for the temporary queues and topics
> so we can trap temporary.delete(). That way we will know we don't
> need to do it on close()
> IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will
> also need to trap these destinations to do the necessary wrapping/unwrapping.
> It is also possible to retrieve a temporary destination with Session.createQueue/Topic.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:33:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Fri, 22 Sep 2006 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30593466.1158935581446.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3685?page=comments#action_12343851 ] 
            
Kabir Khan commented on JBAS-3685:
----------------------------------

Good catch, I've fixed it

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:33:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1908) listMessageCounter
 issue with JMS
 subscriptions containing certain message selector characters
Message-ID: <1428265.1158935581923.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1908?page=all ]

Adrian Brock updated JBAS-1908:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> listMessageCounter issue with JMS subscriptions containing certain message selector characters
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-1908
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1908
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP Professional, JDK1.4.2_06, JBoss 4.0.2
>            Reporter: Jaco Joubert
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: DestinationManager.txt, DestinationMBeanSupport.txt, listCounter.jar, MessageCounter.txt, test-topic-service.xml
>
>
> When the message selector query for a subscription to a JMS topic looks someting like "field in ('A', 'B', 'C')", two failures occur on JMS MBeans:
> 1.  The listMessageCounter operation on jboss.mq:service=DestinationManager fails with a NumberFormatException:
> Caused by: java.lang.NumberFormatException: For input string: " 'ghi'"
>   at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>   at java.lang.Integer.parseInt(Integer.java:468)
>   at java.lang.Integer.parseInt(Integer.java:518)
>   at org.jboss.mq.server.jmx.DestinationManager.listMessageCounter(DestinationManager.java:477)
>   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:324)
>   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>   ... 44 more
> This is because the getCounterAsString() method is used on the MessageCounter to get the details and then traversed with
> a StringTokenizer tokenizing on commas, but the subscription name also contains commas in this case.
> 2.  The listMessageCounter operation on jboss.mq.destination:name=[topicName],service=Topic works, but the resulting HTML
>     table has some of the selector values populating the counter columns.  The problem is because of the same issue as above.
>     
> This can be reproduced by following these steps:
> 1.  Startup a JBoss4.0.2 with default configuration.
> 2.  Deploy the attached 'test-topic-service.xml'.  This will create a JMS topic called 'counterTestTopic'.
> 3.  Run the attached client (source included in jar).  The only jar needed on classpath is the 'jbossall-client.jar':
>     java -cp "[path]\jbossall-client.jar;.\listCounter.jar" za.co.jdj.jbossmq.testcounter.TestListCounter
>     This will do the following:
>     3.1.  Connect to the JMS server running locally.
>     3.2.  Create a publisher and durable subscriber on the 'counterTestTopic' already deployed.
>           The subscriber has a message selector in the format already described
>     3.3.  Invoke the listMessageCounter operation on jboss.mq:service=DestinationManager, printing the error.
>     3.4.  Wait for the client to look at the html table created by the topic in a browser.
>     3.5.  Remove the subscription and exit.
>     
> Suggested fixes for the problem includes:
> 1.  Add a getDestinationTypeDescription() method to org.jboss.mq.server.MessageCounter.  (See MessageCounter.txt attached)
> 2.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationManager to not use the getCounterAsString() method
>     on org.jboss.mq.server.MessageCounter, but rather extract the values itself for the html table.
>     (See the DestinationManager.txt file attached).
> 3.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationMBeanSupport to do the same as above.
>     (See the DestinationMBeanSupport.txt file attached).

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:36:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3484) non portable JDK
 dependant clasess (sun.**)
In-Reply-To: <23337773.1154968092604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20152787.1158935761310.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3484?page=all ]

Adrian Brock updated JBAS-3484:
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

This task needs updating to say what has been done for 4.0.5
and what will be deferred until 4.0.6

> non portable JDK dependant clasess (sun.**)
> -------------------------------------------
>
>                 Key: JBAS-3484
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3484
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Security
>    Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.0.4.GA
>            Reporter: Andrew Oliver
>             Fix For: JBossAS-4.0.5.GA
>
>
> We should not be using sun.** classes in tests or in code.   they are naughty and break working on non Sun JDKs.
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -i "sun.misc.BASE64Encoder" '{}' ';'
>       sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc.BASE64Encoder" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:   /** Compare Util.encodeBase64 against the sun misc class
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * Eliminates dependency on sun.misc.Base64Encoding,
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * (it's an access exception to load sun.misc.* classes
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.io" '{}' ';'
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:         sun.io.CharToByteUTF8 conv = new sun.io.CharToByteUTF8();
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:      } catch ( sun.io.MalformedInputException e ) {
> [andy at localhost jboss-4.0.x]$
> Moreover the 

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:36:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-638) renamed configuration
 property mail.smtp.host to jbpm.mail.smtp.host
Message-ID: <15185182.1158935761441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-638?page=all ]

Tom Baeyens closed JBPM-638.
----------------------------

    Resolution: Done

> renamed configuration property mail.smtp.host to jbpm.mail.smtp.host
> --------------------------------------------------------------------
>
>                 Key: JBPM-638
>                 URL: http://jira.jboss.com/jira/browse/JBPM-638
>             Project: JBoss jBPM
>          Issue Type: Task
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>            Priority: Minor
>             Fix For: jBPM 3.2 alpha 1
>
>
> this is a minor issue since email support has not been released yet.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:36:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3632) Too early checking
 of not closing connections
In-Reply-To: <10803421.1157628643891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14196274.1158935761598.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3632?page=all ]

Adrian Brock updated JBAS-3632:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> Too early checking of not closing connections
> ---------------------------------------------
>
>                 Key: JBAS-3632
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3632
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> In the case where a transaction is ended early,
> e.g. JBossTM rollsback transactions at a timeout immediately,
> the cached connection manager is firing connection not closed events.
> This is because the ejb is still in the invocation with the connection open
> but the transaction synchronization is fired by the rollback/timeout.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:45:03 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3674) service MetricsLookup
 dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6362560.1158936303414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3674?page=all ]

Adrian Brock closed JBAS-3674.
------------------------------

    Resolution: Out of Date

Help requests belong in the forums.

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:54:05 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 22 Sep 2006 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-602) If LeasePeriod is not
 set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16452111.1158936845345.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-602?page=all ]

Clebert Suconic closed JBREM-602.
---------------------------------


> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:54:05 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 22 Sep 2006 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3687) Test case for Custom
 Principal Propagation
Message-ID: <29849048.1158936845481.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test case for Custom Principal Propagation
------------------------------------------

                 Key: JBAS-3687
                 URL: http://jira.jboss.com/jira/browse/JBAS-3687
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


As indicated in the forum thread, there seems to be an issue with the propagation of caller principal (that is of type Custom Principal).  There is a claim that the principal that is propagated happens to be of type SimplePrincipal.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 11:02:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 22 Sep 2006 11:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3687) Test case for
 Custom Principal Propagation
In-Reply-To: <29849048.1158936845481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30940460.1158937321831.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3687?page=comments#action_12343854 ] 
            
Anil Saldhana commented on JBAS-3687:
-------------------------------------

asaldhana~/jboss-4.0/testsuite>ant -Dtest=org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase one-test
Buildfile: build.xml

one-test:
   [delete] Deleting: C:\cygwin\home\asaldhana\jboss-4.0\testsuite\output\log\test.log
    [junit] Running org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.672 sec

BUILD SUCCESSFUL
Total time: 5 seconds


Not able to reproduce through a personal testcase.

> Test case for Custom Principal Propagation
> ------------------------------------------
>
>                 Key: JBAS-3687
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3687
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> As indicated in the forum thread, there seems to be an issue with the propagation of caller principal (that is of type Custom Principal).  There is a claim that the principal that is propagated happens to be of type SimplePrincipal.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 11:42:06 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 11:42:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-777) FileCacheLoader
 can return
 null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14502461.1158939726071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno reassigned JBCACHE-777:
----------------------------------------

    Assignee: Galder Zamarreno  (was: Manik Surtani)

> FileCacheLoader can return null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) which goes against the JavaDoc 
> requirements for that method:
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If a get(fqn) operation occurrs before a put and the node (directory) does not exist, FCL returns 
> null when it should return an empty Map.
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 12:24:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 22 Sep 2006 12:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3687) Test case for Custom
 Principal Propagation
In-Reply-To: <29849048.1158936845481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19265306.1158942241208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3687?page=all ]

Anil Saldhana closed JBAS-3687.
-------------------------------

    Resolution: Done

> Test case for Custom Principal Propagation
> ------------------------------------------
>
>                 Key: JBAS-3687
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3687
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> As indicated in the forum thread, there seems to be an issue with the propagation of caller principal (that is of type Custom Principal).  There is a claim that the principal that is propagated happens to be of type SimplePrincipal.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:00:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Fri, 22 Sep 2006 13:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-105) Make this JSF
 based system work on JBoss Portal 2.4
In-Reply-To: <7238225.1153926131402.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9133203.1158944401256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-105?page=all ]

Ryszard Kozmik resolved JBFORUMS-105.
-------------------------------------

    Resolution: Done

FINALLY DONE!

> Make this JSF based system work on JBoss Portal 2.4
> ---------------------------------------------------
>
>                 Key: JBFORUMS-105
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-105
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 1 week, 7 hours
>
> Investigate what need to be done to make this work on JBoss Portal 2.4
> Currently supported Portal version = 2.2.1RC1

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:06:01 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Fri, 22 Sep 2006 13:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3684) References to
	TxManager
In-Reply-To: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23956163.1158944761297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3684?page=all ]

Bill Burke updated JBAS-3684:
-----------------------------

    Assignee: William DeCoste  (was: Bill Burke)

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3684
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.
>       ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
>       ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java
> These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:42:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1042) Add AJAX
	request Javascript
In-Reply-To: <13107312.1158456047454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8998182.1158946921461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1042?page=all ]

Roy Russo resolved JBPORTAL-1042.
---------------------------------

    Resolution: Done

> Add AJAX request Javascript
> ---------------------------
>
>                 Key: JBPORTAL-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1042
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Add DOM walker and storing of original values, and try to supply this to backend:
> - window id/window name
> - source coordinates (region / index)
> - destination coordinates (regin / index)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:42:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1011) Drag&drop
	documentation
In-Reply-To: <26617813.1156995824966.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26545044.1158946922289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1011?page=all ]

Roy Russo reassigned JBPORTAL-1011:
-----------------------------------

    Assignee: Roy Russo  (was: Tomasz Szymanski)

>  Drag&drop documentation
> ------------------------
>
>                 Key: JBPORTAL-1011
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1011
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Provide documentation for the drag&drop

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:42:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1009) Drag&drop unit
	tests
In-Reply-To: <30549920.1156995344268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7054807.1158946922674.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1009?page=all ]

Roy Russo reassigned JBPORTAL-1009:
-----------------------------------

    Assignee: Roy Russo  (was: Tomasz Szymanski)

> Drag&drop unit tests
> --------------------
>
>                 Key: JBPORTAL-1009
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1009
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Per Julien:
> - the validation of JsUnit framework
> - it is integrated in the portal testsuite (using some variable to 
> control the browser tested)
> - it is integrated with cruisecontrol with a wide choice a browsers - QA

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:45:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1008) Integrate
 drap&drop theme into the Portal (no persistence)
In-Reply-To: <6025777.1156995224349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19199659.1158947101317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1008?page=all ]

Roy Russo reassigned JBPORTAL-1008:
-----------------------------------

    Assignee: Roy Russo  (was: Tomasz Szymanski)

> Integrate drap&drop theme into the Portal (no persistence)
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1008
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1008
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Julien:
> the theme is integrated within the portal but the usage is made 
> optional until we find a way to control theme degradability to no 
> javascript. Roy and Julien will cooperate on that. For now we only 
> expect no persitence of changes until dashboard is implemented. So 
> changes are stored in http session.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:45:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1008) Integrate
 drap&drop theme into the Portal (no persistence)
In-Reply-To: <6025777.1156995224349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <472239.1158947101461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1008?page=all ]

Roy Russo resolved JBPORTAL-1008.
---------------------------------

    Resolution: Done

> Integrate drap&drop theme into the Portal (no persistence)
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1008
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1008
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Julien:
> the theme is integrated within the portal but the usage is made 
> optional until we find a way to control theme degradability to no 
> javascript. Roy and Julien will cooperate on that. For now we only 
> expect no persitence of changes until dashboard is implemented. So 
> changes are stored in http session.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:45:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1056) Drag/Drop
 dropmarker for better user experience
Message-ID: <14908268.1158947101578.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drag/Drop dropmarker for better user experience
-----------------------------------------------

                 Key: JBPORTAL-1056
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1056
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:53:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 22 Sep 2006 13:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3688) test component field
	required?
Message-ID: <11364463.1158947581013.JavaMail.jira@cloud.prod.atl2.jboss.com>

test component field required?
------------------------------

                 Key: JBAS-3688
                 URL: http://jira.jboss.com/jira/browse/JBAS-3688
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Ryan Campbell
         Assigned To: Ryan Campbell


test if the component field is required

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 14:02:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 22 Sep 2006 14:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-3688) test component field
	required?
Message-ID: <5220647.1158948121191.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3688?page=all ]

Ryan Campbell deleted JBAS-3688:
--------------------------------


> test component field required?
> ------------------------------
>
>                 Key: JBAS-3688
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3688
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Ryan Campbell
>
> test if the component field is required

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 14:26:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 14:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <18170394.1158949561728.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis reassigned JBAS-3683:
----------------------------------------

    Assignee: Dimitris Andreadis

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 14:32:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 14:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <29651206.1158949921282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis updated JBAS-3683:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.6.CR1)

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 15:20:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 22 Sep 2006 15:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1057) Create/update
 DTD/schemas for descriptors.
Message-ID: <11332006.1158952801489.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create/update DTD/schemas for descriptors.
------------------------------------------

                 Key: JBPORTAL-1057
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1057
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.4 Final
            Reporter: Chris Laprun
         Assigned To: Roy Russo
            Priority: Minor
             Fix For: 2.4.1 Final




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 15:23:00 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 22 Sep 2006 15:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1058) Create
 DTD/Schema for WSRP deployment descriptors (-wsrp.xml)
Message-ID: <17592829.1158952980981.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create DTD/Schema for WSRP deployment descriptors (-wsrp.xml)
-------------------------------------------------------------

                 Key: JBPORTAL-1058
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1058
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
            Priority: Minor
             Fix For: 2.4.1 Final




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 15:38:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 22 Sep 2006 15:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-523) implement jmx-name
	in jboss.xml
Message-ID: <11661404.1158953881212.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-523?page=all ]

William DeCoste closed EJBTHREE-523.
------------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
       Resolution: Done

> implement jmx-name in jboss.xml
> -------------------------------
>
>                 Key: EJBTHREE-523
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-523
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC6 - PFD
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>            Priority: Minor
>             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

        


From jira-events at jboss.com  Fri Sep 22 16:02:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 22 Sep 2006 16:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-146) purge rule for ant
 in trailblazer does not remove class files.
Message-ID: <1870121.1158955321220.JavaMail.jira@cloud.prod.atl2.jboss.com>

purge rule for ant in trailblazer does not remove class files.
--------------------------------------------------------------

                 Key: JBESB-146
                 URL: http://jira.jboss.com/jira/browse/JBESB-146
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Examples
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
            Priority: Minor
             Fix For: 4.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

        


From jira-events at jboss.com  Fri Sep 22 16:11:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Fri, 22 Sep 2006 16:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3689) Naming fails to
 accept a custom client socket
Message-ID: <31568337.1158955861048.JavaMail.jira@cloud.prod.atl2.jboss.com>

Naming fails to accept a custom client socket
---------------------------------------------

                 Key: JBAS-3689
                 URL: http://jira.jboss.com/jira/browse/JBAS-3689
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


Attempting to set a custom client socket on the NamingService
   <mbean code="org.jboss.naming.NamingService"
      name="jboss:service=Naming"
      xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
      <!-- The call by value mode. true if all lookups are unmarshalled using
      the caller's TCL, false if in VM lookups return the value by reference.
      -->
      <attribute name="CallByValue">false</attribute>
      <!-- The listening port for the bootstrap JNP service. Set this to -1
        to run the NamingService without the JNP invoker listening port.
      -->
      <attribute name="Port">1099</attribute>
      <attribute name="RmiPort">1098</attribute>
      <!-- The bootstrap JNP server bind address. This also sets the default
      RMI service bind address. Empty == all addresses
       -->
      <attribute name="BindAddress">${iface.A}</attribute>
      <attribute name="RmiBindAddress">${iface.A}</attribute>
      <!-- The thread pool service used to control the bootstrap lookups -->
      <depends optional-attribute-name="LookupPool"
         proxy-type="attribute">jboss.system:service=ThreadPool</depends>
      <attribute name="ClientSocketFactory">case9179.TimeoutClientSocketFactory</attribute>
   </mbean>

fails with:

2006-09-22 12:46:12,417 WARN  [org.jboss.naming.NamingService] Failed to setBindAddress=/192.168.2.107 on socket factory
java.lang.NullPointerException: case9179.TimeoutClientSocketFactory.setBindAddress invoked on null object
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source)
	at org.jnp.server.Main.initCustomSocketFactories(Main.java:355)
	at org.jnp.server.Main.start(Main.java:255)
	at org.jboss.naming.NamingService.startService(NamingService.java:221)

The problem is that there copy/paste error at line 355:

   protected void initCustomSocketFactories()
   {
      // Use either the rmiBindAddress or bindAddress for the RMI service
      InetAddress addr = rmiBindAddress;
      if( addr == null )
         addr = bindAddress;

      if( clientSocketFactory != null )
      {
         // See if the client socket supports setBindAddress(String)
         try
         {
            Class csfClass = clientSocketFactory.getClass();
            Class[] parameterTypes = {String.class};
            Method m = csfClass.getMethod("setBindAddress", parameterTypes);
            Object[] args = {addr.getHostAddress()};
            m.invoke(serverSocketFactory, args); // +++ line 355, This should be clientSocketFactory
         }
         catch (NoSuchMethodException e)
         {
            log.warn("Socket factory does not support setBindAddress(String)");
            // Go with default address
         }


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 18:20:02 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 18:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-526) JMSRedelivered
 flag not correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3408288.1158963602089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Ovidiu Feodorov closed JBMESSAGING-526.
---------------------------------------

    Resolution: Done

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 18:20:02 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 18:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <33261906.1158963602658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 19:08:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 22 Sep 2006 19:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3684) References to
	TxManager
In-Reply-To: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6358785.1158966481294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3684?page=all ]

William DeCoste closed JBAS-3684.
---------------------------------

    Resolution: Done

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3684
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.
>       ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
>       ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java
> These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 19:39:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 22 Sep 2006 19:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-715) complete
 implementation of interceptor-order in ejb-jar.xml
Message-ID: <16762800.1158968341039.JavaMail.jira@cloud.prod.atl2.jboss.com>

complete implementation of interceptor-order in ejb-jar.xml
-----------------------------------------------------------

                 Key: EJBTHREE-715
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-715
             Project: EJB 3.0
          Issue Type: Task
            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

        


From jira-events at jboss.com  Fri Sep 22 22:08:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-550) Add JBoss
 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
In-Reply-To: <5205854.1158809458341.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14399176.1158977281311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-550?page=all ]

Ovidiu Feodorov updated JBMESSAGING-550:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> Add JBoss 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-550
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-550
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:08:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-550) Add JBoss
 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
In-Reply-To: <5205854.1158809458341.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17569573.1158977281615.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-550?page=all ]

Ovidiu Feodorov closed JBMESSAGING-550.
---------------------------------------

    Resolution: Done

> Add JBoss 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-550
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-550
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:11:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <27280870.1158977461118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov updated JBMESSAGING-302:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:11:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <12688862.1158977461253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov closed JBMESSAGING-302.
---------------------------------------

    Resolution: Done

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:29:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 22 Sep 2006 22:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3339)
 ValidConnectionChecker for Sybase DB
Message-ID: <26492737.1158978541097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3339?page=all ]

Weston Price resolved JBAS-3339.
--------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                       (was: JBossAS-4.0.5.GA)
       Resolution: Done

Added SybaseValidConnection checker using equivalent select from dual method

> ValidConnectionChecker for Sybase DB
> ------------------------------------
>
>                 Key: JBAS-3339
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3339
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Weston Price
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta
>
>
> During consulting engagement a feature request for a Sybase validation connection checker was introduced. This would answer an issue for the client where RDBMS systems are brought down for mainteniance and they have to reboot JBossAS instances using Sybase. 

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 00:09:59 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Sat, 23 Sep 2006 00:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-2737)
 InternalManagedConnectionPool.removeTimedOut() should not destroy
 connections below the minimum pool size
Message-ID: <19138516.1158984599756.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2737?page=all ]

Weston Price resolved JBAS-2737.
--------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Added capability to force pool to never destroy connections below min if configured to do so.

> InternalManagedConnectionPool.removeTimedOut() should not destroy connections below the minimum pool size
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2737
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2737
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: SUSE Linux, Sun JDK 1.4.2_08 (though this issue would be relevant to all platforms)
>            Reporter: Jim Paterson
>             Fix For: JBossAS-5.0.0.Beta
>
>
> By default JBoss JDBC connection pools have a 15 minute idle time. Every time the IdleRemover runs it currently destroys every connection in the pool that has not been used in the last 15 minutes. It then establishes new connections if necessary to take the pool back up to its minimum size.
> In most cases this behaviour probably doesn't cause problems. However, in our scenario it does. We are using DB2 and, in some situations, DB2 caches previously compiled query plans on a per connection basis. One specific example we have is a highly optimized search stored procedure that uses temporary tables. The IdleRemover is causing roughly 60% of our calls to this procedure to go through a new connection. This changes the response time from this stored procedure from ~200ms to ~2seconds as if triggers re-compilations in the database. 
> Because of this behaviour we do not want the application server to drop and restore connections unless they are in error or the pool has grown beyond the minimum size during a period of peak load. 
> I can understand that the current implementation protects the application server against stale connections. However, there are other mechanisms in the JDBC connection pool to handle this i.e. the the check-valid-connection-sql and valid-connection-checker-class-name parameters.
> Do you agree that the current implementation should be changed?

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:42:01 2006
From: jira-events at jboss.com (Scott Reed (JIRA))
Date: Sat, 23 Sep 2006 07:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-380) Create some
 decision table examples
In-Reply-To: <10327077.1153833972040.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24754101.1159011721420.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-380?page=comments#action_12343874 ] 
            
Scott Reed commented on JBRULES-380:
------------------------------------

One example for each example in the DRL rule docs would have helped me a lot. 

> Create some decision table examples
> -----------------------------------
>
>                 Key: JBRULES-380
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-380
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Documentation
>    Affects Versions: 3.0
>            Reporter: lyle hayhurst
>         Assigned To: Mark Proctor
>         Attachments: barbarian.xls, dtex.tar.gz, test.rar
>
>   Original Estimate: 1 day
>          Time Spent: 3 hours
>  Remaining Estimate: 1 day
>
> As per IRC, some more fleshed out examples of decision tables in action.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:45:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 23 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-778) Refactor package
	distribution
Message-ID: <31189905.1159011901144.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor package distribution
-----------------------------

                 Key: JBCACHE-778
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-778
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


Per disucssion, we are refactoring the distribution package for release 2.0.

1. jboss-cache-core-dist.zip. Core edition that contains the tradition cache library.
  - Only Cache (jboss-cache.jar) and supporting library
  - Ref doc
  - faq
  - tutorial

2. jboss-cache-pojo-dist.zip. PojoCache edition. It has jboss-cache-core-dist.zip, plus
  - pojocache.jar that contains the PojoCache lib
  - additional JBoss Aop, trove, javassist, jboss-aop-jdk50.jar, qdox.jar
  - PojoCache ref doc
  - faq-pojo for PojoCache
 
3. jboss-cache-all-dist.zip. Everything PojoCache has, plus
 - javadoc
 - src


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:45:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 23 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-779) Split the faq
 directory into faq and faq-pojo
Message-ID: <16060951.1159011901263.JavaMail.jira@cloud.prod.atl2.jboss.com>

Split the faq directory into faq and faq-pojo
---------------------------------------------

                 Key: JBCACHE-779
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-779
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: 2.0.0


faq is for core JBoss Cache while faq-pojo is for PojoCache

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:45:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 23 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-779) Split the faq
 directory into faq and faq-pojo
In-Reply-To: <16060951.1159011901263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32202487.1159011901381.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-779?page=all ]

Ben Wang resolved JBCACHE-779.
------------------------------

    Resolution: Done

> Split the faq directory into faq and faq-pojo
> ---------------------------------------------
>
>                 Key: JBCACHE-779
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-779
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> faq is for core JBoss Cache while faq-pojo is for PojoCache

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:51:01 2006
From: jira-events at jboss.com (Scott Reed (JIRA))
Date: Sat, 23 Sep 2006 07:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-501) DRL -> decision
 table (round trip)
Message-ID: <7645154.1159012261138.JavaMail.jira@cloud.prod.atl2.jboss.com>

DRL -> decision table (round trip)
----------------------------------

                 Key: JBRULES-501
                 URL: http://jira.jboss.com/jira/browse/JBRULES-501
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Scott Reed
         Assigned To: Mark Proctor


It would be extremely useful to be able to convert existing rules to decision tables. The educational value alone would make it worth while, but it would speed up development as well since the DRL -> decision table mapping is not straight forward and cell merging and coloring is fairly tedious. 

Users would probably want to be able to select the rules and functions to be mapped. If so, then the results of the mapping would have to be one or more decision table files and a new DRL file containing the rules and functions that were not converted.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:33:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-338) Changes to
 SeamInterceptor break non-JSF calls.
In-Reply-To: <8417461.1156344946502.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18089338.1159014781294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-338?page=all ]

Gavin King closed JBSEAM-338.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done

fixed, but not properly tested

> Changes to SeamInterceptor break non-JSF calls.
> -----------------------------------------------
>
>                 Key: JBSEAM-338
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-338
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> The CVS changes to SeamInterceptor have it call Component.forName() outside of the Seam contexts when called via MDB or RMI. Need to call beginCall(), endCall() from the @PostConstruct and @PostActivate methods.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:33:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-358) Adding
 core.FacesMessages requires JSF libraries to compile component
In-Reply-To: <21739116.1158918901085.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5633910.1159014781450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-358?page=comments#action_12343876 ] 
            
Gavin King commented on JBSEAM-358:
-----------------------------------

No, this is not the reason for it. FacesMessages is totally dependent to JSF for its functionality and even its API.

> Adding core.FacesMessages requires JSF libraries to compile component
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-358
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-358
>             Project: JBoss Seam
>          Issue Type: Bug
>            Reporter: Christian Bauer
>            Priority: Minor
>
> I have this in a Seam component:
>     // For error messages
>     @In(create=true)
>     private FacesMessages facesMessages;
> This is org.jboss.seam.core.FacesMessages. It doesn't extend anything from JSF but I still can't compile my Seam component without the JSF stubs on the classpath:
> /Users/turin/work/local/lab8/modules/beans/src/auction/beans/PlaceBidImpl.java
>     Error:Error:line (112)cannot access javax.faces.application.FacesMessage
> file javax/faces/application/FacesMessage.class not found
> This is inconvenient because this is the only JSF compile-time dependency in all of my Seam components and I have to add the JSF libs to my compile classpath just for this. I don't really know why this is required... because of the static methods in FacesMessages?
> In any case, it would be nice to be able to send JSF messages without binding the component to JSF and I initially thought that this was the usecase for core.FacesMessages in Seam.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:36:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-358) Adding
 core.FacesMessages requires JSF libraries to compile component
In-Reply-To: <21739116.1158918901085.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1759034.1159014961169.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-358?page=all ]

Gavin King closed JBSEAM-358.
-----------------------------

    Resolution: Won't Fix

> Adding core.FacesMessages requires JSF libraries to compile component
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-358
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-358
>             Project: JBoss Seam
>          Issue Type: Bug
>            Reporter: Christian Bauer
>            Priority: Minor
>
> I have this in a Seam component:
>     // For error messages
>     @In(create=true)
>     private FacesMessages facesMessages;
> This is org.jboss.seam.core.FacesMessages. It doesn't extend anything from JSF but I still can't compile my Seam component without the JSF stubs on the classpath:
> /Users/turin/work/local/lab8/modules/beans/src/auction/beans/PlaceBidImpl.java
>     Error:Error:line (112)cannot access javax.faces.application.FacesMessage
> file javax/faces/application/FacesMessage.class not found
> This is inconvenient because this is the only JSF compile-time dependency in all of my Seam components and I have to add the JSF libs to my compile classpath just for this. I don't really know why this is required... because of the static methods in FacesMessages?
> In any case, it would be nice to be able to send JSF messages without binding the component to JSF and I initially thought that this was the usecase for core.FacesMessages in Seam.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:39:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-359) Abstract Seam core
 components from JSF-EL
Message-ID: <15279714.1159015141124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Abstract Seam core components from JSF-EL
-----------------------------------------

                 Key: JBSEAM-359
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-359
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King


Currently a bunch of core components (and possibly other stuff) calls to JSF for EL evaluation. We have already said we will migrate to using the unified EL stuff. However, the user should be able to plug in their own EL (eg. OGNL), so we should introduce a new core component ExpressionEvaluator to allow custom creation of MethodBindings and ValueBindings.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 09:00:01 2006
From: jira-events at jboss.com (Scott Reed (JIRA))
Date: Sat, 23 Sep 2006 09:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-502) Add binding
 semantics for decision table authors
Message-ID: <3845829.1159016401254.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add binding semantics for decision table authors
------------------------------------------------

                 Key: JBRULES-502
                 URL: http://jira.jboss.com/jira/browse/JBRULES-502
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Scott Reed
         Assigned To: Mark Proctor


The expressive capability of decision tables for non-programmer authors is limited.  Especially, the author has no way to tell the developer to use the value of a property from one column in the condition for another. I can think of two ways that binding semantics could be added:
  Use the comment cells (i.e. "Age: Person's Age") - this is simple and expressive but would cause problems if an author wants to use the '<word>:' construct in a comment without intending it to be a binding.
  Add a designated row above or below the comment row.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 10:06:01 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 23 Sep 2006 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-501) DRL -> decision
 table (round trip)
In-Reply-To: <7645154.1159012261138.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25391831.1159020361364.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-501?page=comments#action_12343877 ] 
            
Mark Proctor commented on JBRULES-501:
--------------------------------------

its a nice idea, but I don't see how this  would work - as many rules do not map well to decision tables.  Still you can try this  one yourself. You can take a Package and then use the xml/drl dumper as examples on how to dump to a different format.

> DRL -> decision table (round trip)
> ----------------------------------
>
>                 Key: JBRULES-501
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-501
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Scott Reed
>         Assigned To: Mark Proctor
>
> It would be extremely useful to be able to convert existing rules to decision tables. The educational value alone would make it worth while, but it would speed up development as well since the DRL -> decision table mapping is not straight forward and cell merging and coloring is fairly tedious. 
> Users would probably want to be able to select the rules and functions to be mapped. If so, then the results of the mapping would have to be one or more decision table files and a new DRL file containing the rules and functions that were not converted.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 10:15:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 23 Sep 2006 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <32003728.1159020901152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis closed JBAS-3641.
------------------------------------

    Resolution: Done

Updated.

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>         Attachments: jboss_init_hpux.sh, jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 10:39:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 23 Sep 2006 10:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <25291334.1159022341335.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3683?page=comments#action_12343879 ] 
            
Dimitris Andreadis commented on JBAS-3683:
------------------------------------------

Thanks! Why you changed some counters to Gauge32 and left 2 of them as INTEGER?

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:51:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-355) Constructor
 injection of component dependencies
In-Reply-To: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24926422.1159026661061.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-355?page=comments#action_12343880 ] 
            
Gavin King commented on JBSEAM-355:
-----------------------------------

The reason I don't support constructor injection is that I can't do constructor injection for session beans 'cos EJB3 doesn't support it (there is a reason for this, btw).


> Constructor injection of component dependencies
> -----------------------------------------------
>
>                 Key: JBSEAM-355
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Minor
>
> Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 
> Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.
> Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:54:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-47) Entity beans and
 session replication
Message-ID: <11095584.1159026841315.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-47?page=comments#action_12343881 ] 
            
Gavin King commented on JBSEAM-47:
----------------------------------

This can now be handled my @Mutable .... should we make @Mutable a default for @Entity?

> Entity beans and session replication
> ------------------------------------
>
>                 Key: JBSEAM-47
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-47
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>
> We need to force HttpSession puts for entity bean and java bean components to ensure that state changes get replicated...

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:54:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-47) Entity beans and
 session replication
Message-ID: <17575421.1159026841507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-47?page=all ]

Gavin King updated JBSEAM-47:
-----------------------------

    Priority: Minor  (was: Major)

Downgrading, 'cos it is now just a question of sensible defaulting.

> Entity beans and session replication
> ------------------------------------
>
>                 Key: JBSEAM-47
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-47
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Minor
>
> We need to force HttpSession puts for entity bean and java bean components to ensure that state changes get replicated...

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:57:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-351) method instance() in
 userPrincipal should be static
In-Reply-To: <29304742.1158151114106.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23119061.1159027021364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-351?page=all ]

Gavin King closed JBSEAM-351.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

thanks, fixed

> method instance() in userPrincipal should be static
> ---------------------------------------------------
>
>                 Key: JBSEAM-351
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-351
>             Project: JBoss Seam
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 1.1
>            Reporter: Michael Steiner
>         Assigned To: Gavin King
>            Priority: Trivial
>             Fix For: 1.1
>
>         Attachments: patch.txt
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:57:03 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-332) javabeans in
 session are not distributable
In-Reply-To: <13441536.1155654861191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12650451.1159027023664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-332?page=all ]

Gavin King updated JBSEAM-332:
------------------------------

    Priority: Critical  (was: Major)

upgrading

> javabeans in session are not distributable
> ------------------------------------------
>
>                 Key: JBSEAM-332
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-332
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0, JBoss 4.0.4GA, Windows Server 2003, Cluster of 4 nodes on 2 machines.
>            Reporter: Keith Naas
>         Assigned To: Gavin King
>            Priority: Critical
>         Attachments: itpa.ear, itpa.ear
>
>
> We have an application that makes use of JavaBeans for a lot of our JSF "actions".  When one of our nodes is brought down, the session should Seamlessly failover to another node.  The user is sent  to a different node, but the entire session appears to be in a clean state.   We looked through the server logs and saw the following:
> 2006-08-15 10:47:36,658 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheService] [.......] loadSession(): id: GWrcdSJEASvXSJnX6fNHNg**exception occurred during serialization: java.lang.ClassNotFoundException: No ClassLoaders found for: com.ourapp.web.beans.WorksheetBean$$EnhancerByCGLIB$$bf40374c
> All of our beans are Serializable, but it appears that there is an issue with the cache sync of the CGLib proxy classes.  This specific bean does have some service properties that are transients.  It also has properties that refer to other Web JavaBeans.  
> We will be investigating this some more, but we wanted to get this logged since it appears to be a major issue that prevents us from clustering our Seam apps.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-360) Seam managed
 persistence contexts and clusters
Message-ID: <1571973.1159027381169.JavaMail.jira@cloud.prod.atl2.jboss.com>

Seam managed persistence contexts and clusters
----------------------------------------------

                 Key: JBSEAM-360
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-360
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
            Priority: Critical
             Fix For: 1.1


I have designed a new mechanism which allows:

(1) efficiencies when using replicated EPCs
(2) fix for a bug when using a Seam-managed EPC in a cluster

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-360) Seam managed
 persistence contexts and clusters
In-Reply-To: <1571973.1159027381169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6241306.1159027381285.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-360?page=all ]

Gavin King closed JBSEAM-360.
-----------------------------

    Resolution: Done

> Seam managed persistence contexts and clusters
> ----------------------------------------------
>
>                 Key: JBSEAM-360
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-360
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> I have designed a new mechanism which allows:
> (1) efficiencies when using replicated EPCs
> (2) fix for a bug when using a Seam-managed EPC in a cluster

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-361) Support
 @PrePassivate, 
 @PostActivate, @PostConstruct for JavaBean components and interceptors
Message-ID: <12292647.1159027381423.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support @PrePassivate, @PostActivate, @PostConstruct for JavaBean components and interceptors
---------------------------------------------------------------------------------------------

                 Key: JBSEAM-361
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-361
             Project: JBoss Seam
          Issue Type: Feature Request
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Support a richer lifecycle in both Seam interceptors and Seam JavaBean components.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-361) Support
 @PrePassivate, 
 @PostActivate, @PostConstruct for JavaBean components and interceptors
In-Reply-To: <12292647.1159027381423.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23526124.1159027381562.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-361?page=all ]

Gavin King closed JBSEAM-361.
-----------------------------

    Resolution: Done

> Support @PrePassivate, @PostActivate, @PostConstruct for JavaBean components and interceptors
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-361
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-361
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Support a richer lifecycle in both Seam interceptors and Seam JavaBean components.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:09:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-362) Improvements to
	compnents.xml
Message-ID: <5637850.1159027741125.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improvements to compnents.xml
-----------------------------

                 Key: JBSEAM-362
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-362
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


The following improvements:

(1) Let scope be specified
(2) allow components to be wired via EL
(3) allow multi-valued properties to be initialized
(4) create an alias for another component

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:09:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-362) Improvements to
	compnents.xml
In-Reply-To: <5637850.1159027741125.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5289355.1159027741296.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-362?page=all ]

Gavin King closed JBSEAM-362.
-----------------------------

    Resolution: Done

> Improvements to compnents.xml
> -----------------------------
>
>                 Key: JBSEAM-362
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-362
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> The following improvements:
> (1) Let scope be specified
> (2) allow components to be wired via EL
> (3) allow multi-valued properties to be initialized
> (4) create an alias for another component

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:11:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-363) Make pageflow
 component into a user visible API
Message-ID: <7913515.1159027861071.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make pageflow component into a user visible API
-----------------------------------------------

                 Key: JBSEAM-363
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-363
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1




-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:11:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-363) Make pageflow
 component into a user visible API
In-Reply-To: <7913515.1159027861071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6957688.1159027861177.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-363?page=all ]

Gavin King closed JBSEAM-363.
-----------------------------

    Resolution: Done

> Make pageflow component into a user visible API
> -----------------------------------------------
>
>                 Key: JBSEAM-363
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-363
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:13:04 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-132) Annotation for
 redirect on exception
Message-ID: <6313231.1159027984137.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-132?page=comments#action_12343885 ] 
            
Gavin King commented on JBSEAM-132:
-----------------------------------

Note this encompasses @Render, @HttpError and @Redirect

> Annotation for redirect on exception
> ------------------------------------
>
>                 Key: JBSEAM-132
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-132
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Arash Bijanzadeh
>         Assigned To: Gavin King
>            Priority: Optional
>             Fix For: 1.1
>
>
> It would be very nice if you could add an anotation to seam which redirects a specific type of exception to a specific outcome. 

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:16:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-320) client-side
	interceptors
In-Reply-To: <33405608.1153952051370.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9390257.1159028161310.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-320?page=comments#action_12343886 ] 
            
Gavin King commented on JBSEAM-320:
-----------------------------------

Note this also involved replacing @Within and @Around with @Interceptor

> client-side interceptors
> ------------------------
>
>                 Key: JBSEAM-320
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-320
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:34:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-364) Use reflection in
 org.jboss.seam.util.Persistence
Message-ID: <20736586.1159029241179.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use reflection in org.jboss.seam.util.Persistence
-------------------------------------------------

                 Key: JBSEAM-364
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-364
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
            Reporter: Gavin King
            Priority: Critical


Currently we got a hard dependence to Hibernate. We should use reflection in this class.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:40:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Sat, 23 Sep 2006 12:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-355) Constructor
 injection of component dependencies
In-Reply-To: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11490381.1159029601189.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-355?page=comments#action_12343887 ] 
            
Christian Bauer commented on JBSEAM-355:
----------------------------------------

OK, but why not offer it for entities?


> Constructor injection of component dependencies
> -----------------------------------------------
>
>                 Key: JBSEAM-355
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Minor
>
> Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 
> Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.
> Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.

-- 
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

        


From wealthy888 at yahoo.com  Sun Sep 24 00:15:33 2006
From: wealthy888 at yahoo.com (¨ÕÃ³Õ)
Date: Sun, 24 Sep 2006 00:15:33
Subject: [jboss-jira] =?iso-8859-1?q?=E0=BB=C5=D5=E8=C2=B9=E0=C7=C5=D2=CB?=
	=?iso-8859-1?q?=C5=D1=A7=E0=C5=D4=A1=A7=D2=B9=E0=BB=E7=B9=E0=A7=D4?=
	=?iso-8859-1?q?=B9=24=24=24?=
Message-ID: <200609231715.k8NHFXfL026316@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060924/3f168ba4/attachment.html 

From jira-events at jboss.com  Sat Sep 23 14:28:01 2006
From: jira-events at jboss.com (John Gilbert (JIRA))
Date: Sat, 23 Sep 2006 14:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-147) Document Design
 Notes on Interaction Differences in the New Architecture
Message-ID: <19387768.1159036081405.JavaMail.jira@cloud.prod.atl2.jboss.com>

Document Design Notes on Interaction Differences in the New Architecture
------------------------------------------------------------------------

                 Key: JBESB-147
                 URL: http://jira.jboss.com/jira/browse/JBESB-147
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0
            Reporter: John Gilbert
         Assigned To: Mark Little
            Priority: Minor


Wiki Page: http://wiki.jboss.org/wiki/Wiki.jsp?page=InteractionDifferencesInTheNewArchitecture

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 14:49:05 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 14:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-28) Possibility to
 choose Forums first view.
Message-ID: <21354811.1159037345538.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-28?page=comments#action_12343888 ] 
            
Ryszard Kozmik commented on JBFORUMS-28:
----------------------------------------

It is possible in new Forums.
If you want to have summary view as the default setting for every user the only thing you have to change is one of values of managed bean called "defaultPreferences" found in forums-config.xml.
Setting value of property "summarytopiclimit" to 0 will turn off summary view. Nevertheless each user can override this value in his preferences value. So, if he want summary view he can have one just for himself.

> Possibility to choose Forums first view.
> ----------------------------------------
>
>                 Key: JBFORUMS-28
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-28
>             Project: JBoss Forums
>          Issue Type: Feature Request
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 30 minutes
>
> It would be good to have possibility to choose between "Latest posted topics" view and normal forums' categories view as the first JBForums normal view.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 14:49:06 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 14:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-28) Possibility to
 choose Forums first view.
Message-ID: <27712240.1159037346138.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-28?page=all ]

Ryszard Kozmik resolved JBFORUMS-28.
------------------------------------

    Resolution: Done

> Possibility to choose Forums first view.
> ----------------------------------------
>
>                 Key: JBFORUMS-28
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-28
>             Project: JBoss Forums
>          Issue Type: Feature Request
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 30 minutes
>
> It would be good to have possibility to choose between "Latest posted topics" view and normal forums' categories view as the first JBForums normal view.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 14:58:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 14:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-123) On preview topic
 view "Powered by JBoss Portal" tag flies around
Message-ID: <4351983.1159037881234.JavaMail.jira@cloud.prod.atl2.jboss.com>

On preview topic view "Powered by JBoss Portal" tag flies around
----------------------------------------------------------------

                 Key: JBFORUMS-123
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-123
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.0.0 Alpha
            Reporter: Ryszard Kozmik
         Assigned To: Ryszard Kozmik
            Priority: Minor


While creating topic with preview the theme tag "Powered by JBoss Portal / Theme by ***" flies over forums.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 15:01:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 15:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-124) Repair links to
 communicators, private message and e-mail
Message-ID: <30912966.1159038061046.JavaMail.jira@cloud.prod.atl2.jboss.com>

Repair links to communicators, private message and e-mail
---------------------------------------------------------

                 Key: JBFORUMS-124
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-124
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.0.0 Alpha
            Reporter: Ryszard Kozmik
         Assigned To: Ryszard Kozmik
            Priority: Minor


After adding all information for user about his/her communicators, e-mail etc. TopicView and UserView is showing exceptions connected with generating wrong URL structure for communicators/e-mail buttons.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 15:04:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 15:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-125) BBCode URL Tag
	improvement
Message-ID: <3889348.1159038241186.JavaMail.jira@cloud.prod.atl2.jboss.com>

BBCode URL Tag improvement
--------------------------

                 Key: JBFORUMS-125
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-125
             Project: JBoss Forums
          Issue Type: Feature Request
          Components: Forum Enhancements
            Reporter: Ryszard Kozmik
             Fix For: 1.1.0 Alpha


BBCode's URL tag could work similar to html "a href" style like : [url=http://www.example.com]My Example[/url]

-- 
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

        


From c13 at fullmailmarket.com  Sat Sep 23 15:56:09 2006
From: c13 at fullmailmarket.com (ADSL Pyme!)
Date: Sat, 23 Sep 2006 15:56:09 -0400
Subject: [jboss-jira] ADSL Pyme-Empresas
Message-ID: <200609231956.k8NJu9YU030380@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060923/4ca00c73/attachment.html 

From jira-events at jboss.com  Sat Sep 23 16:13:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 16:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-126) NewTopic on
 ForumsView doesn't work on IE
Message-ID: <7318128.1159042381055.JavaMail.jira@cloud.prod.atl2.jboss.com>

NewTopic on ForumsView doesn't work on IE
-----------------------------------------

                 Key: JBFORUMS-126
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-126
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.0.0 Alpha
            Reporter: Ryszard Kozmik
         Assigned To: Ryszard Kozmik
            Priority: Minor


Creating topic by NewTopic button on ForumsView is not possible when browsing Forums using IE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 16:55:01 2006
From: jira-events at jboss.com (Luca Stancapiano (JIRA))
Date: Sat, 23 Sep 2006 16:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
Message-ID: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>

testsuite on web about single sign on wrong (I think...)
--------------------------------------------------------

                 Key: JBAS-3690
                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.0.4.GA
         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
            Reporter: Luca Stancapiano


on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 17:07:01 2006
From: jira-events at jboss.com (Gerald Turner (JIRA))
Date: Sat, 23 Sep 2006 17:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <24200965.1159045621286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3683?page=comments#action_12343889 ] 
            
Gerald Turner commented on JBAS-3683:
-------------------------------------

Dimitris, the reason that I changed some types to Gauge32 is because NET-SNMP complains about the type returned by the SNMP Agent not matching the MIB -  though I don't recall if these were merely warnings versus failure like the other syntax errors.  The reason I left some as INTEGER is because snmp-adaptor / RequestHandlerImpl converts Long attributes to SnmpUInt32 (Gauge32), and Integer attributes to SnmpInt32 (INTEGER), for example jboss.system:type=ServerInfo ActiveThreadCount is an Integer, thus it matced the MIB.

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 17:58:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 17:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-124) Repair links to
 communicators, private message and e-mail
In-Reply-To: <30912966.1159038061046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26710825.1159048681240.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-124?page=all ]

Ryszard Kozmik updated JBFORUMS-124:
------------------------------------

    Fix Version/s: 1.0.0 Alpha

Forgot to set Fix Version

> Repair links to communicators, private message and e-mail
> ---------------------------------------------------------
>
>                 Key: JBFORUMS-124
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-124
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>
> After adding all information for user about his/her communicators, e-mail etc. TopicView and UserView is showing exceptions connected with generating wrong URL structure for communicators/e-mail buttons.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 18:01:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 18:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-126) NewTopic on
 ForumsView doesn't work on IE
In-Reply-To: <7318128.1159042381055.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14730525.1159048861113.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-126?page=all ]

Ryszard Kozmik updated JBFORUMS-126:
------------------------------------

    Fix Version/s: 1.0.0 Alpha

Forgot to set Fix Version

> NewTopic on ForumsView doesn't work on IE
> -----------------------------------------
>
>                 Key: JBFORUMS-126
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-126
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>
> Creating topic by NewTopic button on ForumsView is not possible when browsing Forums using IE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 18:01:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 18:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-123) On preview topic
 view "Powered by JBoss Portal" tag flies around
In-Reply-To: <4351983.1159037881234.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2498831.1159048861232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-123?page=all ]

Ryszard Kozmik updated JBFORUMS-123:
------------------------------------

    Fix Version/s: 1.0.0 Alpha

Forgot to set Fix Version

> On preview topic view "Powered by JBoss Portal" tag flies around
> ----------------------------------------------------------------
>
>                 Key: JBFORUMS-123
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-123
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>
> While creating topic with preview the theme tag "Powered by JBoss Portal / Theme by ***" flies over forums.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 18:13:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-124) Repair links to
 communicators, private message and e-mail
In-Reply-To: <30912966.1159038061046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13726449.1159049581329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-124?page=all ]

Ryszard Kozmik resolved JBFORUMS-124.
-------------------------------------

    Resolution: Done

> Repair links to communicators, private message and e-mail
> ---------------------------------------------------------
>
>                 Key: JBFORUMS-124
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-124
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 3 hours
>
> After adding all information for user about his/her communicators, e-mail etc. TopicView and UserView is showing exceptions connected with generating wrong URL structure for communicators/e-mail buttons.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 00:40:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 00:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
Message-ID: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>

TransactionManager service config in services/config still refers to ArjunaTS
-----------------------------------------------------------------------------

                 Key: JBTM-129
                 URL: http://jira.jboss.com/jira/browse/JBTM-129
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Jonathan Halliday
            Priority: Minor
             Fix For: 4.4


So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 01:52:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 01:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
In-Reply-To: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17830911.1159077122111.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-128?page=comments#action_12343896 ] 
            
Mark Little commented on JBTM-128:
----------------------------------

This is a result of using interoposition on a remote transaction manager: the TM is not local so there will be no BasicAction instance. The code needs to duplicate the contents of the ClassCastException to cover this:

try
			{
				/*
				 * If this is an imported transaction and we have just performed
				 * interposition, then register a purely local Synchronization.
				 * This gets us over a performance issue with JacORB.
				 */

				theTx = (TwoPhaseCoordinator) BasicAction.Current();

                                if (theTx != null) // TM is local
				    theTx.addSynchronization(new LocalCleanupSynchronization(this));
                                else
                                    registerSynchronization(new CleanupSynchronization(this));
			}
			catch (ClassCastException ex)
			{
				/*
				 * Not a local/interposed transaction.
				 */

				registerSynchronization(new CleanupSynchronization(this));
			}

> warning with TransactionManager interface in JTS with external TM
> -----------------------------------------------------------------
>
>                 Key: JBTM-128
>                 URL: http://jira.jboss.com/jira/browse/JBTM-128
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
>            Reporter: Jonathan Halliday
>         Assigned To: Mark Little
>
> When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:
> 2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
> java.lang.NullPointerException
>         at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
>         at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)
> This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.
> Test code to reproduce warning:
>         System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
>         System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
>         ORB myORB = ORB.getInstance("ServerSide");
>         OA myOA = OA.getRootOA(myORB);
>         myORB.initORB(args, null);
>         myOA.initOA();
>         javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
>         transactionManager.begin();
>         transactionManager.commit();

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 01:55:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 01:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
In-Reply-To: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9893211.1159077301523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-128?page=all ]

Mark Little updated JBTM-128:
-----------------------------

    Fix Version/s: 4.2.2

> warning with TransactionManager interface in JTS with external TM
> -----------------------------------------------------------------
>
>                 Key: JBTM-128
>                 URL: http://jira.jboss.com/jira/browse/JBTM-128
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
>            Reporter: Jonathan Halliday
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:
> 2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
> java.lang.NullPointerException
>         at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
>         at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)
> This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.
> Test code to reproduce warning:
>         System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
>         System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
>         ORB myORB = ORB.getInstance("ServerSide");
>         OA myOA = OA.getRootOA(myORB);
>         myORB.initORB(args, null);
>         myOA.initOA();
>         javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
>         transactionManager.begin();
>         transactionManager.commit();

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 01:55:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 01:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
In-Reply-To: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7350386.1159077302065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-128?page=all ]

Mark Little closed JBTM-128.
----------------------------

    Resolution: Done

> warning with TransactionManager interface in JTS with external TM
> -----------------------------------------------------------------
>
>                 Key: JBTM-128
>                 URL: http://jira.jboss.com/jira/browse/JBTM-128
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
>            Reporter: Jonathan Halliday
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:
> 2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
> java.lang.NullPointerException
>         at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
>         at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)
> This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.
> Test code to reproduce warning:
>         System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
>         System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
>         ORB myORB = ORB.getInstance("ServerSide");
>         OA myOA = OA.getRootOA(myORB);
>         myORB.initORB(args, null);
>         myOA.initOA();
>         javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
>         transactionManager.begin();
>         transactionManager.commit();

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:37:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
In-Reply-To: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22789304.1159079821407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-129?page=all ]

Mark Little reassigned JBTM-129:
--------------------------------

    Assignee: Mark Little  (was: Jonathan Halliday)

> TransactionManager service config in services/config still refers to ArjunaTS
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-129
>                 URL: http://jira.jboss.com/jira/browse/JBTM-129
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:37:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
In-Reply-To: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26651713.1159079821566.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-129?page=all ]

Mark Little updated JBTM-129:
-----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)

> TransactionManager service config in services/config still refers to ArjunaTS
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-129
>                 URL: http://jira.jboss.com/jira/browse/JBTM-129
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-71) Bank example still
 refers to ArjunaTS
Message-ID: <32128541.1159081081253.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-71?page=comments#action_12343898 ] 
            
Mark Little commented on JBTM-71:
---------------------------------

So did TxStats, recoveryservice.conf, recoverymanagerservice.sh and many other files.

> Bank example still refers to ArjunaTS
> -------------------------------------
>
>                 Key: JBTM-71
>                 URL: http://jira.jboss.com/jira/browse/JBTM-71
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-71) Bank example still
 refers to ArjunaTS
Message-ID: <1188651.1159081081408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-71?page=all ]

Mark Little updated JBTM-71:
----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)])

> Bank example still refers to ArjunaTS
> -------------------------------------
>
>                 Key: JBTM-71
>                 URL: http://jira.jboss.com/jira/browse/JBTM-71
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:22:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-71) Bank example still
 refers to ArjunaTS
Message-ID: <4603331.1159082521767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-71?page=all ]

Mark Little closed JBTM-71.
---------------------------

    Resolution: Done

> Bank example still refers to ArjunaTS
> -------------------------------------
>
>                 Key: JBTM-71
>                 URL: http://jira.jboss.com/jira/browse/JBTM-71
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:22:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
In-Reply-To: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29952887.1159082521924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-129?page=all ]

Mark Little closed JBTM-129.
----------------------------

    Resolution: Done

> TransactionManager service config in services/config still refers to ArjunaTS
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-129
>                 URL: http://jira.jboss.com/jira/browse/JBTM-129
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:22:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-88) Patch for making
 source compilable with JDK1.5.0
Message-ID: <26753802.1159082522799.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-88?page=all ]

Mark Little reassigned JBTM-88:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Patch for making source compilable with JDK1.5.0
> ------------------------------------------------
>
>                 Key: JBTM-88
>                 URL: http://jira.jboss.com/jira/browse/JBTM-88
>             Project: JBoss Transaction Manager
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: Java
>            Reporter: Lorenz Froihofer
>         Assigned To: Jonathan Halliday
>         Attachments: jdk1.5.0.diff
>
>
> This patch makes the JBossTS sources compilable with JDK1.5.0. It was created by performing a diff against the sources provided in jbossts-full-4.2.1Beta1-src.zip

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:25:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-28) Replace existing
 JBoss transaction implementation in JBoss 5.0 with local JTA
Message-ID: <1948226.1159082701938.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-28?page=all ]

Mark Little reassigned JBTM-28:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Replace existing JBoss transaction implementation in JBoss 5.0 with local JTA
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-28
>                 URL: http://jira.jboss.com/jira/browse/JBTM-28
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation, WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.6
>
>
> No separate plugin: default JTA implementation out-of-the-box.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:28:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-75) Update transactional
 JDBC driver to support JDBC 3 methods.
Message-ID: <15891063.1159082881344.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-75?page=all ]

Mark Little reassigned JBTM-75:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Update transactional JDBC driver to support JDBC 3 methods.
> -----------------------------------------------------------
>
>                 Key: JBTM-75
>                 URL: http://jira.jboss.com/jira/browse/JBTM-75
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>            Priority: Minor
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:28:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-88) Patch for making
 source compilable with JDK1.5.0
Message-ID: <27203193.1159082881522.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-88?page=all ]

Mark Little updated JBTM-88:
----------------------------

    Fix Version/s: 4.4

> Patch for making source compilable with JDK1.5.0
> ------------------------------------------------
>
>                 Key: JBTM-88
>                 URL: http://jira.jboss.com/jira/browse/JBTM-88
>             Project: JBoss Transaction Manager
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: Java
>            Reporter: Lorenz Froihofer
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>         Attachments: jdk1.5.0.diff
>
>
> This patch makes the JBossTS sources compilable with JDK1.5.0. It was created by performing a diff against the sources provided in jbossts-full-4.2.1Beta1-src.zip

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-47) Tidy up the online
	manuals
Message-ID: <30150164.1159083241210.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-47?page=all ]

Mark Little updated JBTM-47:
----------------------------

    Priority: Minor  (was: Major)

> Tidy up the online manuals
> --------------------------
>
>                 Key: JBTM-47
>                 URL: http://jira.jboss.com/jira/browse/JBTM-47
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation, Documentation
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>
> The online manuals (html) were generated from Word (SaveAs->HTML[Filtered]) and it hasn't done a great job. For a start, tabs are represented as ?. We need to fix this so that the presentation is consistent with the pdf manuals.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-72) Trail map neglects to
 remind reader to start recovery manager
Message-ID: <21954542.1159083241827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-72?page=all ]

Mark Little reassigned JBTM-72:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Trail map neglects to remind reader to start recovery manager
> -------------------------------------------------------------
>
>                 Key: JBTM-72
>                 URL: http://jira.jboss.com/jira/browse/JBTM-72
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:37:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26027095.1159083421780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little updated JBTM-110:
-----------------------------

    Priority: Minor  (was: Major)

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16656693.1159084141506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little closed JBTM-110.
----------------------------

    Resolution: Cannot Reproduce Bug

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5336679.1159084141695.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little reopened JBTM-110:
------------------------------

             

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25110162.1159084141827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little updated JBTM-110:
-----------------------------

    Fix Version/s: 4.2.2

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5645359.1159084141957.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little closed JBTM-110.
----------------------------

    Resolution: Done

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-113) Move timeout text
	from JTS to core
In-Reply-To: <24125928.1154260211382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4159775.1159084862056.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-113?page=all ]

Mark Little updated JBTM-113:
-----------------------------

    Fix Version/s: 4.2.2

> Move timeout text from JTS to core
> ----------------------------------
>
>                 Key: JBTM-113
>                 URL: http://jira.jboss.com/jira/browse/JBTM-113
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-113) Move timeout text from
	JTS to core
In-Reply-To: <24125928.1154260211382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22287782.1159084862223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-113?page=all ]

Mark Little closed JBTM-113.
----------------------------

    Resolution: Done

> Move timeout text from JTS to core
> ----------------------------------
>
>                 Key: JBTM-113
>                 URL: http://jira.jboss.com/jira/browse/JBTM-113
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-73) Update trailmap text
 to remove Arjuna references
Message-ID: <28658340.1159084862369.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-73?page=all ]

Mark Little updated JBTM-73:
----------------------------

    Fix Version/s: 4.2.2

> Update trailmap text to remove Arjuna references
> ------------------------------------------------
>
>                 Key: JBTM-73
>                 URL: http://jira.jboss.com/jira/browse/JBTM-73
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>
> Trailmap text still talks about ArjunaTS.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-73) Update trailmap text to
 remove Arjuna references
Message-ID: <4873459.1159084862591.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-73?page=all ]

Mark Little closed JBTM-73.
---------------------------

    Resolution: Done

> Update trailmap text to remove Arjuna references
> ------------------------------------------------
>
>                 Key: JBTM-73
>                 URL: http://jira.jboss.com/jira/browse/JBTM-73
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Trailmap text still talks about ArjunaTS.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:16:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-96) XARecoveryModule does
 not use I18N logger in all info cases
In-Reply-To: <18100816.1152614531748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30571961.1159085761966.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-96?page=all ]

Mark Little updated JBTM-96:
----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)

> XARecoveryModule does not use I18N logger in all info cases
> -----------------------------------------------------------
>
>                 Key: JBTM-96
>                 URL: http://jira.jboss.com/jira/browse/JBTM-96
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:22:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-96) XARecoveryModule does
 not use I18N logger in all info cases
In-Reply-To: <18100816.1152614531748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19888203.1159086121994.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-96?page=all ]

Mark Little closed JBTM-96.
---------------------------

    Resolution: Done

> XARecoveryModule does not use I18N logger in all info cases
> -----------------------------------------------------------
>
>                 Key: JBTM-96
>                 URL: http://jira.jboss.com/jira/browse/JBTM-96
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 20 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:25:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-85) BasicXARecovery
 example class is broken
Message-ID: <22282843.1159086301799.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-85?page=all ]

Mark Little updated JBTM-85:
----------------------------

    Fix Version/s: 4.2.2

> BasicXARecovery example class is broken
> ---------------------------------------
>
>                 Key: JBTM-85
>                 URL: http://jira.jboss.com/jira/browse/JBTM-85
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> The BasicXARecovery example class in the distribution is broken. When getting the attributes from the property file, the line:
>  String dynamicClass = new String(dbTag+user+dynamicClassTag);
> should be:
>     String dynamicClass = new String(dbTag+number+dynamicClassTag);

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:31:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-85) BasicXARecovery example
 class is broken
Message-ID: <29915965.1159086661805.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-85?page=all ]

Mark Little closed JBTM-85.
---------------------------

    Resolution: Done

> BasicXARecovery example class is broken
> ---------------------------------------
>
>                 Key: JBTM-85
>                 URL: http://jira.jboss.com/jira/browse/JBTM-85
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, Documentation
>    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
>
> The BasicXARecovery example class in the distribution is broken. When getting the attributes from the property file, the line:
>  String dynamicClass = new String(dbTag+user+dynamicClassTag);
> should be:
>     String dynamicClass = new String(dbTag+number+dynamicClassTag);

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-82) Make sure that
 xaRecoveryNode is mentioned in setup
Message-ID: <13644019.1159086841720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-82?page=all ]

Mark Little updated JBTM-82:
----------------------------

    Fix Version/s: 4.2.2

> Make sure that xaRecoveryNode is mentioned in setup
> ---------------------------------------------------
>
>                 Key: JBTM-82
>                 URL: http://jira.jboss.com/jira/browse/JBTM-82
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-82) Make sure that
 xaRecoveryNode is mentioned in setup
Message-ID: <28955164.1159086841931.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-82?page=all ]

Mark Little closed JBTM-82.
---------------------------

    Resolution: Done

> Make sure that xaRecoveryNode is mentioned in setup
> ---------------------------------------------------
>
>                 Key: JBTM-82
>                 URL: http://jira.jboss.com/jira/browse/JBTM-82
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    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
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:37:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-66) "Already marked for
 rollback" Exception could include original cause
Message-ID: <27290147.1159087022698.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-66?page=all ]

Mark Little reassigned JBTM-66:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> "Already marked for rollback" Exception could include original cause
> --------------------------------------------------------------------
>
>                 Key: JBTM-66
>                 URL: http://jira.jboss.com/jira/browse/JBTM-66
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>         Environment: JBoss 4.0.4.CR2
>            Reporter: Richard Kennard
>         Assigned To: Jonathan Halliday
>            Priority: Optional
>             Fix For: 4.6
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> First up, thank you for providing such a wondefully stable implementation! I have a small feature request:
> At present whenever a, say, SFSB throws a RuntimeException, JTA goes into 'rollback' mode. From then on, anyone who tries to do any further work (including when the SessionContext tries to remove the rolled back SFSB) will trigger a different RuntimeException saying, in short, 'Already marked for rollback'.
> It would be very helpful if the 'Already marked for rollback' Exception could include, as its getCause (which is standard as of JDK 1.4), the original exception that started off the rollback? At present we are often left with the situation where all the original caller gets back is a 'Already marked for rollback' Exception, and there is no way to 'drill down' to find what the original cause was.
> Of course, you could also argue that the SessionContext should be smarter about trying to remove rolled back EJBs.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:37:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-66) "Already marked for
 rollback" Exception could include original cause
Message-ID: <23102284.1159087022896.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-66?page=all ]

Mark Little updated JBTM-66:
----------------------------

        Fix Version/s: 4.6
    Affects Version/s: 4.2
                           (was: 4.4)

> "Already marked for rollback" Exception could include original cause
> --------------------------------------------------------------------
>
>                 Key: JBTM-66
>                 URL: http://jira.jboss.com/jira/browse/JBTM-66
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>         Environment: JBoss 4.0.4.CR2
>            Reporter: Richard Kennard
>         Assigned To: Jonathan Halliday
>            Priority: Optional
>             Fix For: 4.6
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> First up, thank you for providing such a wondefully stable implementation! I have a small feature request:
> At present whenever a, say, SFSB throws a RuntimeException, JTA goes into 'rollback' mode. From then on, anyone who tries to do any further work (including when the SessionContext tries to remove the rolled back SFSB) will trigger a different RuntimeException saying, in short, 'Already marked for rollback'.
> It would be very helpful if the 'Already marked for rollback' Exception could include, as its getCause (which is standard as of JDK 1.4), the original exception that started off the rollback? At present we are often left with the situation where all the original caller gets back is a 'Already marked for rollback' Exception, and there is no way to 'drill down' to find what the original cause was.
> Of course, you could also argue that the SessionContext should be smarter about trying to remove rolled back EJBs.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:43:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-106) log if
 setTransactionTimeout on XAResource fails
In-Reply-To: <7964029.1153926971381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16042709.1159087381732.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-106?page=all ]

Mark Little updated JBTM-106:
-----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.6)

> log if setTransactionTimeout on XAResource fails
> ------------------------------------------------
>
>                 Key: JBTM-106
>                 URL: http://jira.jboss.com/jira/browse/JBTM-106
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Trivial
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:46:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-106) log if
 setTransactionTimeout on XAResource fails
In-Reply-To: <7964029.1153926971381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10390962.1159087561930.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-106?page=all ]

Mark Little closed JBTM-106.
----------------------------

    Resolution: Done

> log if setTransactionTimeout on XAResource fails
> ------------------------------------------------
>
>                 Key: JBTM-106
>                 URL: http://jira.jboss.com/jira/browse/JBTM-106
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Trivial
>             Fix For: 4.2.2
>
>          Time Spent: 10 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:46:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-121) Check recovery
In-Reply-To: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9017545.1159087562103.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-121?page=all ]

Mark Little reassigned JBTM-121:
--------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> Check recovery
> --------------
>
>                 Key: JBTM-121
>                 URL: http://jira.jboss.com/jira/browse/JBTM-121
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.4
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-80) consistent naming for
	jars
Message-ID: <3724698.1159087741367.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-80?page=all ]

Mark Little updated JBTM-80:
----------------------------

        Fix Version/s: 4.4
    Affects Version/s: 4.2

> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-80) consistent naming for
	jars
Message-ID: <32909985.1159087741544.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-80?page=all ]

Mark Little reassigned JBTM-80:
-------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-118) JTA manual example on
 transactional driver is out of date.
In-Reply-To: <16502287.1155290772947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4174587.1159088281325.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-118?page=all ]

Mark Little updated JBTM-118:
-----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)

> JTA manual example on transactional driver is out of date.
> ----------------------------------------------------------
>
>                 Key: JBTM-118
>                 URL: http://jira.jboss.com/jira/browse/JBTM-118
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Optional
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:01:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-118) JTA manual example on
 transactional driver is out of date.
In-Reply-To: <16502287.1155290772947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10934714.1159088461445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-118?page=all ]

Mark Little closed JBTM-118.
----------------------------

    Resolution: Done

> JTA manual example on transactional driver is out of date.
> ----------------------------------------------------------
>
>                 Key: JBTM-118
>                 URL: http://jira.jboss.com/jira/browse/JBTM-118
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Optional
>             Fix For: 4.2.2
>
>          Time Spent: 20 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:01:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-122) Requalify WS-TX 1.0
 interop against IBM/Microsoft endpoints
In-Reply-To: <33145092.1157558490997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16400844.1159088461599.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-122?page=all ]

Mark Little updated JBTM-122:
-----------------------------

    Fix Version/s: 4.2.2

> Requalify WS-TX 1.0 interop against IBM/Microsoft endpoints
> -----------------------------------------------------------
>
>                 Key: JBTM-122
>                 URL: http://jira.jboss.com/jira/browse/JBTM-122
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:01:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-81) Delay start of
	recovery manager
Message-ID: <26261048.1159088461775.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-81?page=all ]

Mark Little updated JBTM-81:
----------------------------

    Fix Version/s: 4.2.2

> Delay start of recovery manager
> -------------------------------
>
>                 Key: JBTM-81
>                 URL: http://jira.jboss.com/jira/browse/JBTM-81
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace:
> 10:52:35,529 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\
> l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource
> java.io.StreamCorruptedException: unexpected end of block data
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\
> Module.java:178)
> This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:56:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 05:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-780) PojoCache to use
 pojocache-aop.xml
Message-ID: <27689009.1159091761416.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to use pojocache-aop.xml
----------------------------------

                 Key: JBCACHE-780
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-780
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


Previously, we have always use jboss-aop.xml as the configuration file for PojoCache and JBoss Aop. This is not adequate in 2.0 anymore becuase we have annotation plus additional interceptors stack and Obervable pattern. Therefore, I have decided to rename it into pojocache-aop.xml for PojoCache specific configuration.

If there is additional user-defined aop.xml fiel, e.g., via non-annotated way, then it can be named under user-aop.xml. From JBoss Aop point of view, all we need is to define the system property jboss.aop.path to include multiple *-aop.xml files.


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:56:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 05:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-780) PojoCache to use
 pojocache-aop.xml
In-Reply-To: <27689009.1159091761416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25929889.1159091761571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-780?page=all ]

Ben Wang resolved JBCACHE-780.
------------------------------

    Resolution: Done

> PojoCache to use pojocache-aop.xml
> ----------------------------------
>
>                 Key: JBCACHE-780
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-780
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Previously, we have always use jboss-aop.xml as the configuration file for PojoCache and JBoss Aop. This is not adequate in 2.0 anymore becuase we have annotation plus additional interceptors stack and Obervable pattern. Therefore, I have decided to rename it into pojocache-aop.xml for PojoCache specific configuration.
> If there is additional user-defined aop.xml fiel, e.g., via non-annotated way, then it can be named under user-aop.xml. From JBoss Aop point of view, all we need is to define the system property jboss.aop.path to include multiple *-aop.xml files.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 08:23:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 08:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
Message-ID: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
---------------------------------------------------------------------------------------------

                 Key: JBCOMMON-10
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.0.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 08:27:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 08:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
In-Reply-To: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7161163.1159100821267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-10?page=all ]

Scott M Stark updated JBCOMMON-10:
----------------------------------

    Fix Version/s: 1.0.0.GA
                   2.0.1.GA

> org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-10
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.0.0.CR1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>
> At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 08:27:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 08:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
In-Reply-To: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24365287.1159100821440.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-10?page=all ]

Scott M Stark updated JBCOMMON-10:
----------------------------------

    Affects Version/s: 2.0.0.GA
                       1.0.0.CR1
                           (was: 1.0.0.GA)

> org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-10
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.0.0.CR1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>
> At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-931) jBPM Integration
	for CMS
Message-ID: <4829962.1159104361459.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-931?page=all ]

Roy Russo reassigned JBPORTAL-931:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> jBPM Integration for CMS
> ------------------------
>
>                 Key: JBPORTAL-931
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-931
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Roy Russo
>         Assigned To: Sohil Shah
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-372) Basic Publish
 Approval Workflow
Message-ID: <12193380.1159104361795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-372?page=all ]

Roy Russo reassigned JBPORTAL-372:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> Basic Publish Approval Workflow
> -------------------------------
>
>                 Key: JBPORTAL-372
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-372
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: James Williams
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> Optional feature which mandates that  content changes must flow through a simple approval process that involves a Publisher and one or more Managers. Once the publisher makes a content change an email approval request should be sent to the manager list. The content change will not be made available to readers until all Managers approve the change.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-532) Define CMS
	security
Message-ID: <20822762.1159104362102.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-532?page=all ]

Roy Russo reassigned JBPORTAL-532:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> Define CMS security
> -------------------
>
>                 Key: JBPORTAL-532
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-532
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Sohil Shah
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Explore the different possbilities of the cms security :
> - define what resources are secured (it should be directories and content)
> - define the security model : the different actions on nodes and their relationship accross the resources (i.e what implies what between different resources)
> - see if the new portal security module can handle that
> - where to apply runtime checks

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-328) CMS security
Message-ID: <2986445.1159104362381.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-328?page=all ]

Roy Russo reassigned JBPORTAL-328:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> CMS security
> ------------
>
>                 Key: JBPORTAL-328
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-328
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Sohil Shah
>             Fix For: 2.6.Alpha1
>
>
> Improve the current CMS security.
> No check is done at the CMSPortlet level, this is a important missing feature.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:29:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1007916.1159104541333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Roy Russo resolved JBPORTAL-964.
--------------------------------

    Fix Version/s: 2.6.Alpha1
       Resolution: Done

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 10:11:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 10:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
In-Reply-To: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14875286.1159107061232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-10?page=all ]

Scott M Stark closed JBCOMMON-10.
---------------------------------

    Resolution: Done

> org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-10
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.0.0.CR1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>
> At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 14:11:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 14:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <8539906.1159121461506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis updated JBAS-3683:
-------------------------------------

    Attachment: attributes.mib

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: attributes.mib, snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 14:14:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 14:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <6955734.1159121641162.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis closed JBAS-3683.
------------------------------------

    Resolution: Done

I've attached the corrected MIB in case you want to run it through the compiler again. In fact, we have little experience and resources in developing a decent MIB so we could use some help if you are interested.

Thanks again.

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: attributes.mib, snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 14:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 14:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3346)
 org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase
 causes 1.5 BEA JVM to core dump
Message-ID: <22304321.1159124341558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3346?page=all ]

Dimitris Andreadis closed JBAS-3346.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Won't Fix

By reading the related bugzilla/redhat entry it is clear the core dump appears only using the 62-bit BEA JDK, and doesn't happen using the 32-bit BEA JDK.

I don't think there is much we can do in the jboss codebase about this.

> org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase causes 1.5 BEA JVM to core dump
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3346
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: RHEL 4, x86_64 processor, BEA 1,5 JDK
>            Reporter: Len DiMaggio
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>
> With this JDK:
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> BEA JRockit(R) (build dra-45238-20050523-2021-linux-x86_64, R25.2.0-28)
> And this test from the JBoss 4.0.4/GA test suite (download from jboss.com) - the test causes a code dump when it executes line 62.
>      1	/*
>      2	* JBoss, Home of Professional Open Source
>      3	* Copyright 2005, JBoss Inc., and individual contributors as indicated
>      4	* by the @authors tag. See the copyright.txt in the distribution for a
>      5	* full listing of individual contributors.
>      6	*
>      7	* This is free software; you can redistribute it and/or modify it
>      8	* under the terms of the GNU Lesser General Public License as
>      9	* published by the Free Software Foundation; either version 2.1 of
>     10	* the License, or (at your option) any later version.
>     11	*
>     12	* This software is distributed in the hope that it will be useful,
>     13	* but WITHOUT ANY WARRANTY; without even the implied warranty of
>     14	* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>     15	* Lesser General Public License for more details.
>     16	*
>     17	* You should have received a copy of the GNU Lesser General Public
>     18	* License along with this software; if not, write to the Free
>     19	* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>     20	* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>     21	*/
>     22	package org.jboss.test.cmp2.batchcascadedelete.test;
>     23	
>     24	import org.jboss.test.JBossTestCase;
>     25	import org.jboss.test.cmp2.batchcascadedelete.ejb.Child;
>     26	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildHome;
>     27	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildUtil;
>     28	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildHome;
>     29	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildUtil;
>     30	import org.jboss.test.cmp2.batchcascadedelete.ejb.Parent;
>     31	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentHome;
>     32	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentUtil;
>     33	import junit.framework.Test;
>     34	
>     35	/**
>     36	 * @author <a href="mailto:alex at jboss.org">Alexey Loubyansky</a>
>     37	 * @version <tt>$Revision: 1.1.2.2 $</tt>
>     38	 */
>     39	public class BatchCascadeDeleteUnitTestCase
>     40	   extends JBossTestCase
>     41	{
>     42	   /**
>     43	    * Constructor for the JBossTestCase object
>     44	    *
>     45	    * @param name Test case name
>     46	    */
>     47	   public BatchCascadeDeleteUnitTestCase(String name)
>     48	   {
>     49	      super(name);
>     50	   }
>     51	
>     52	   public static Test suite() throws Exception
>     53	   {
>     54	      return JBossTestCase.getDeploySetup(BatchCascadeDeleteUnitTestCase.class, "cmp2-batchcascadedelete.jar");
>     55	   }
>     56	
>     57	   public void testCase4540() throws Exception
>     58	   {
>     59	      ParentHome parentHome = ParentUtil.getHome();
>     60	      Parent parent = parentHome.create("parent");
>     61	
>     62	      ChildHome childHome = ChildUtil.getHome();
>     63	      Child child = childHome.create( parent, "child");
>     64	
>     65	      GrandchildHome grandchildHome = GrandchildUtil.getHome();
>     66	
>     67	      // If you comment out the next line, then the call to child.remove() works fine.
>     68	      grandchildHome.create(child.getId(), "grandchild");
>     69	
>     70	      this is the test for non-null foreign key
>     71	      child.remove();
>     72	   }
>     73	}
> Here's the dump file:
> Linux x86_64-4as.lab.boston.redhat.com 2.6.9-39.ELsmp #1 SMP Thu Jun 1 18:01:55 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> ===== BEGIN DUMP =============================================================
> JRockit dump produced after 0 days, 00:29:38 on Wed Jun 21 13:56:36 2006
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Error Message: Illegal memory access. [54]
> Signal info  : si_signo=12, si_code=-6
> Version      : BEA JRockit(R) R25.2.0-28 dra-45238-20050523-2021-linux-x86_64
> GC           : System optimized over throughput (initial strategy singleparpar)
>              : GC strategy for GC 4 was genparpar
>              : GC strategy for GC 5 was singleparpar
>              : GC strategy for GC 6 was genparpar
>              : GC strategy for GC 7 was singleparpar
>              : GC strategy for GC 8 was genparpar
>              : mmHeap->data = 0x20000000, mmHeap->top = 0x28000000
>              : mmStartCompaction = 0x21800000, mmEndCompaction = 0x22000000
> CPU          : Intel Pentium 4 SSE SSE2 NetBurst EM64T
> Number CPUs  : 2
> Tot Phys Mem : 4120244224
> OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 4 Beta)
> Linux version 2.6.9-39.ELsmp (bhcompile at hs20-bc1-6.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Thu Jun 1 18:01:55 EDT 2006
> State        : JVM is running (Main thread has finished)
> Command Line : -Djrockit.launcher.type=jrockit.shipment -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/lib/endorsed org.jboss.Main -c all
> Environment  : JAVA_HOME=(null), java.home=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre, java.class.path=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar, java.library.path=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/../lib/amd64
> C Heap       : Good; no memory allocations have failed
> Registers (from context struct at 0x40e899f8/0x40e89a70):
> RAX = ffffffff00000010  RBX = 00000000f7bc5de8
> RCX = 00000000f7bc5df8  RDX = 00000000ffcb1bf3
> R8  = 000000000002feeb  R9  = 000000009090feeb
> R10 = 0000002a9b7aeed0  R11 = 0000002a9577893c
> R12 = 0000000040e89e58  R13 = 0000000000000001
> R14 = 0000000000000001  R15 = 0000002a9b7aed08
> RSI = 0000000020c8bb78  RDI = 00000000220b1108
> RSP = 0000000040e89eb0  RIP = 00000001009ccec8
> RBP = 00000000220b1108  RFL = 00000206
> CS = 0000 GS = 0000 FS = 0000
> Stack:
> 0000000040e89eb0: 0000000021ff0238 00000001009ccbb5 00000000220d6b28 0000000020c81130 0000000022078920 0000000021ff0238 
> 0000000040e89ee0: 0000000100000a22 0000000003c3d730 00000000220d6b40 0000000020c8bb48 0000000022078920 0000000021ff0238 
> 0000000040e89f10: 00000001009ca128 00000001009c9fdf 0000000022078920 0000000020c70cb0 00000000220b22a8 00000000220924a8 
> 0000000040e89f40: 0000000020c8bb48 0000000021ff0238 0000000022078920 0000000020c6ed78 00000001009c9c23 0000000020c6ee40 
> 0000000040e89f70: 0000000100000a45 000000000000001c 0000000021ff0238 0000000020c6ed78 0000000022078920 0000000021ff0238 
> 0000000040e89fa0: 00000001009c9b55 0000000020c137d8 00000001009c8e0f 0000000000000000 0000000022078920 0000000020b0b3b8 
> 0000000040e89fd0: 0000000021ff0238 0000000020c8b568 0000000000000000 0000000021ff0238 0000000020c137d8 0000000021ff0238 
> 0000000040e8a000: 0000000021ff0238 00000001009c8cb5 0000000020c0f3d8 00000001009c8bd4 0000000020c10a90 0000000003c064b0 
> 0000000040e8a030: 0000000021ff0238 0000000020c0f3d8 00000001009c8a8f 0000000003c057f0 0000000020a5ddb0 00000000220924a8 
> 0000000040e8a060: 00000001009c8296 0000000000000001 0000002a9b7aed08 000000010000090f 00000000005d7cd0 0000002a9b7aeed0 
> 0000000040e8a090: 00000000a6bf41f8 0000000020c0dca8 0000000021ff0238 0000000000000000 0000000020a5ddb0 0000000003bffb80 
> 0000000040e8a0c0: 0000000021ff0238 0000000000000000 0000000020a5ddb0 00000000220924a8 00000001009c7386 0000000020a5ddb0 
> 0000000040e8a0f0: 03c028209b7aed08 0000002a9b7aeed8 0000000020c0dca8 0000000000000000 00000000220924a8 0000000021ff0238 
> 0000000040e8a120: 0000000000000000 00000000220924a8 000000000000012c 0000002a9b7aeed0 0000000100000000 000000010002bdf0 
> 0000000040e8a150: 0000000020c08a38 0000000020a5ddb0 0000000100000a22 0000000003c00cf8 0000000000000001 00000000274b8c38 
> 0000000040e8a180: 0000000020c08a38 0000000021ff0238 00000001009c6da7 0000000100000a45 0000000020c0dca8 0000000021ff0238 
> 0000000040e8a1b0: 0000000000000000 0000000000000000 0000000021ff0238 00000001009c62a0 0000000021ff0238 0000000020c07368 
> 0000000040e8a1e0: 00000001009c612a 00000000005d7c90 0000000020c07368 0000000021ff0238 0000000021103b10 0000000000000000 
> 0000000040e8a210: 0000000021ff0238 0000000100000a45 000000000000001c 0000002a969f1010 0000000003bf6978 0000000020c05d48 
> 0000000040e8a240: 0000000021ff0238 00000001009c5b5f 0000000021ff0238 0000000000000000 0000000021ff4240 0000000020c05d48 
> 0000000040e8a270: 0000000021ff0238 0000000020b0b3b8 0000000021ff0238 00000001009c58b4 00000000210fb030 0000000040e8a3e0 
> 0000000040e8a2a0: 0000000020a5ddb0 00000001009c4f23 00000000269f9f90 0000000020b0b3b8 0000000021ff0238 0000000021033388 
> 0000000040e8a2d0: 0000010bf7bc5c80 00000000210fb030 0000002a00000001 0000000000000000 0000002a9b7aed08 0000002a956ad0b1 
> 0000000040e8a300: 000000000000029c 0000000002645f21 0000002a9b7aeec0 0000000040e8a598 0000000040e8a3e0 0000000040e8a560 
> 0000000040e8a330: 0000000100030068 0000000040e8a4f8 0000000040e8a3e0 00000001009c4b10 0000002a9b7aeb20 0000002a9b7aed08 
> 0000000040e8a360: 0000000000000001 0000000000000001 0000000040e8a3e0 0000002a9b7aed08 000000000064ca60 0000002a9560787a 
> 0000000040e8a390: 0000000000000002 0000002a956d3107 0000000103bb9370 000000000056aaa8 0000000040e8a500 0000002a9b7aee48 
> 0000000040e8a3c0: 0000002a9b7b3b00 0000002a956aca24 0000000003bb9370 0000000002643f80 0000002a9b7aee48 0000002a9b7aeec0 
> 0000000040e8a3f0: 0000000000000000 0000000100000000 0000000100000001 0000002a9b7aed28 0000000003bb9370 0000002a9b7aed08 
> 0000000040e8a420: 000000000056aaa8 0000000100000007 0000000200000001 0000000200000000 0000002a00000000 0000002a956c3228 
> 0000000040e8a450: 03bc261800000000 0000000002643f80 0000002a9b7aed08 0000002a9b7b3b00 0000002a9b7aee48 0000002a956c36f0 
> 0000000040e8a480: 0000000000000000 0000002a956c337c 0000002a956c36f0 0000000040e8a4f8 0000000040e8a500 0000000002643f80 
> 0000000040e8a4b0: 0000000000000001 0000002a9b7aee48 0000000000000000 0000002a9b7aed08 0000000002643f80 0000002a956c37c9 
> 0000000040e8a4e0: 011f3cc000000000 0000000040e8a4f8 000000010003af7a 0000002a9b7aeec8 0000000040e8a598 0000002a9b7aed08 
> 0000000040e8a510: 00000001001ecc8b 0000002a9b7aee58 0000002a9b7aeb20 0000000040e8a560 0000000000000001 0000000000000001 
> 0000000040e8a540: 0000002a9b7aed08 0000002a956cc14a 0000002a9b7aee48 000000010003c1e0 0000000000688b30 0000002a9b7aee48 
> 0000000040e8a570: 000000002192dec8 000000010003bfa7 0000000020b0b3b8 0000000021ff6d58 000000010003bea6 0000000021ff6be8 
> 0000000040e8a5a0: 0000000021ff6d58 0000000020b0b3b8 0000000021ff6be8 0000000100000001 0000000020b0b3b8 0000000020b0b3b8 
> 0000000040e8a5d0: 0000000021ff6be8 000000010005db3e 0000000021ff6be8 0000000021ff6d58 0000000020b0b3b8 0000000021ff6d98 
> 0000000040e8a600: 000000010003bd09 0000000021ff6be8 0000000021ff6be8 0000000021ff6be8 0000000020fa8d58 000000010003b2d5 
> 0000000040e8a630: 0000000021ff6be8 0000000020b0b3b8 0000000001939c68 0000000100003945 00000000200a1118 0000000025179958 
> 0000000040e8a660: 0000000000000001 000000000193de20 0000000021ff6c80 0000000020fa8d58 000000010023c5c8 0000000021ff6be8 
> 0000000040e8a690: 00000000ffffffff 0000000021ff6d10 0000000020ffd028 0000000021ff6c80 0000000020fa8d58 0000000020b0b3b8 
> Code:
> 00000001009ccdc8: 894890ff672533e8 c3d2f8252c8b48f3 0001025188b84803 ff6362c8e8000000 0e7ee82824748948 482824748b48ff67 
> 00000001009ccdf8: 00002a9b7ca2b8bf 26048b273c8b4800 7c8b48ff670fa3e8 0e16e826048b0824 0f0ee826048bff69 ee8948f78948ff67 
> 00000001009cce28: 90004d8b241c8948 50b848ff6bef21e8 9000000000010531 df8948ff63626be8 25048b4864f38948 28468948000000d8 
> 00000001009cce58: de8948ff647717e8 894890ff67249be8 ede81024748b48f3 85e8de8948ff6364 cccccccc90ff6724 8bfe8948f38948cf 
> 00000001009cce88: ffffffe0b848260c 480114ffffffffff 67b8c189c389de89 c1c889e9f7666666 89c2011fe8c104fa c82928c96bd189d8 
> 00000001009cceb8: 08768b48137fc085 1776084639d8f748 48c35b10c6748b48 127608463908768b 48c35b10c6748b48 000001009ccec6b8 
> 00000001009ccee8: 009cced6b848f400 ccccccf400000001 cccccccccccccccc 8b4840ec83485553 854820408b483846 4800000213840fc0 
> 00000001009ccf18: 4de838768b48f389 05e8f58948000002 8948c18948ff75bb 314830244c8948d8 44894838708b48db 0c8b20768b480824 
> 00000001009ccf48: e8ffff43e1e89026 24548b48ff63622c 89480824448b4830 244c8948ee8948f1 0093e910768b4828 8948304e8b480000 
> 00000001009ccf78: 8948d58948382474 8948cd2948302454 0c8b0824448948c6 48ffe4d635e89020 d53948d88948c289 480774c08548737c 
> 00000001009ccfa8: b84826eb38245c8b 00000000011df298 f38948ff6360f3e8 5c8948ff66b3dbe8 481024448b481024 48df894838245c8b 
> Loaded modules:
> (* denotes the module causing the exception)
> 0x400000-0x411037  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/bin/java
> 0x3a5dc00000-0x3a5dc0eff9  /lib64/tls/libpthread.so.0
> 0x3a5d400000-0x3a5d48459b  /lib64/tls/libm.so.6
> 0x3a5cf00000-0x3a5cf01c73  /lib64/libdl.so.2
> 0x3a5d100000-0x3a5d22ac59  /lib64/tls/libc.so.6
> 0x3a5cd00000-0x3a5cd1434f  /lib64/ld-linux-x86-64.so.2
> 0x2a95588000-0x2a957a660f  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit/libjvm.so
> 0x2a959e3000-0x2a959ecf13  /lib64/libnss_files.so.2
> 0x2a96c6f000-0x2a96c93473  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libjava.so
> 0x2a96d99000-0x2a96da5627  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libverify.so
> 0x3a62e00000-0x3a62e134eb  /lib64/libnsl.so.1
> 0x2a99d9f000-0x2a99db3fcf  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libnet.so
> 0x2a99eb6000-0x2a99ebed33  /lib64/libnss_nis.so.2
> 0x2a99fc0000-0x2a99fc38a3  /lib64/libnss_dns.so.2
> 0x3a5e200000-0x3a5e210d9b  /lib64/libresolv.so.2
> 0x2a9b5c8000-0x2a9b5c897b  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/librmi.so
> "RMI TCP Connection(4)-192.168.7" id=149 idx=0xc8 tid=1088993632 lastJavaFrame=(nil)
> Thread Stack Trace:
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Extended, platform specific info:
> libc release: 2.3.4-stable
> Elf headers:
> libc       ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5d11c4a0 PHOFF: 0x40 SHOFF: 0x13d5a8 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 69 STIDX: 66
> libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5dc05620 PHOFF: 0x40 SHOFF: 0x12980 EF: 0x0 HS: 64 PS: 56 PHN; 9 SS: 64 SHN: 38 STIDX: 35
> libjvm     ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x36c80 PHOFF: 0x40 SHOFF: 0x3106f0 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
> ===== END DUMP ===============================================================

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 15:02:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24821147.1159124521080.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3659?page=comments#action_12343912 ] 
            
Dimitris Andreadis commented on JBAS-3659:
------------------------------------------

Brian, we've started getting OOMEs in the testsuite runs, could this be related?

> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 15:08:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 15:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1740) Remote Connection
 does not get closed in case of sloppy client
Message-ID: <1528398.1159124881277.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1740?page=comments#action_12343913 ] 
            
Dimitris Andreadis commented on JBAS-1740:
------------------------------------------

Weston, u working on this for 4.0.5? The parent tasks doesn't have a fix release assigned.

> Remote Connection does not get closed in case of sloppy client
> --------------------------------------------------------------
>
>                 Key: JBAS-1740
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1740
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. 
> This can be solved rather easily, the finalize method of the Server part of the proxy should call close.
> Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called.
> This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work with.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 15:11:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Sun, 24 Sep 2006 15:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1740) Remote Connection
 does not get closed in case of sloppy client
Message-ID: <27973025.1159125061261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1740?page=all ]

Weston Price updated JBAS-1740:
-------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                       (was: JBossAS-4.0.5.GA)

Modfied according to JCA roadmap meeting.

> Remote Connection does not get closed in case of sloppy client
> --------------------------------------------------------------
>
>                 Key: JBAS-1740
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1740
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta
>
>
> If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. 
> This can be solved rather easily, the finalize method of the Server part of the proxy should call close.
> Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called.
> This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work with.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 21:02:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 21:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-778) Refactor package
	distribution
In-Reply-To: <31189905.1159011901144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23507969.1159146121047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-778?page=all ]

Ben Wang resolved JBCACHE-778.
------------------------------

    Resolution: Done

> Refactor package distribution
> -----------------------------
>
>                 Key: JBCACHE-778
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-778
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Per disucssion, we are refactoring the distribution package for release 2.0.
> 1. jboss-cache-core-dist.zip. Core edition that contains the tradition cache library.
>   - Only Cache (jboss-cache.jar) and supporting library
>   - Ref doc
>   - faq
>   - tutorial
> 2. jboss-cache-pojo-dist.zip. PojoCache edition. It has jboss-cache-core-dist.zip, plus
>   - pojocache.jar that contains the PojoCache lib
>   - additional JBoss Aop, trove, javassist, jboss-aop-jdk50.jar, qdox.jar
>   - PojoCache ref doc
>   - faq-pojo for PojoCache
>  
> 3. jboss-cache-all-dist.zip. Everything PojoCache has, plus
>  - javadoc
>  - src

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 21:05:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 21:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-781) PojoCache creates
 a separate pojocache.jar for distro
Message-ID: <14717249.1159146301455.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache creates a separate pojocache.jar for distro
-----------------------------------------------------

                 Key: JBCACHE-781
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-781
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Critical
             Fix For: 2.0.0


In 2.0 release, we have created a separate jar file for PojoCache only: pojocache.jar, while keeping jboss-cache.jar to core Cache library. PojoCache users will need to put both pojocache.jar and jboss-cache.jar in their class path.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 21:05:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 21:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-781) PojoCache creates
 a separate pojocache.jar for distro
In-Reply-To: <14717249.1159146301455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27921653.1159146301583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-781?page=all ]

Ben Wang resolved JBCACHE-781.
------------------------------

    Resolution: Done

> PojoCache creates a separate pojocache.jar for distro
> -----------------------------------------------------
>
>                 Key: JBCACHE-781
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-781
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> In 2.0 release, we have created a separate jar file for PojoCache only: pojocache.jar, while keeping jboss-cache.jar to core Cache library. PojoCache users will need to put both pojocache.jar and jboss-cache.jar in their class path.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 23:51:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 23:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-782) Rename
 Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
Message-ID: <20747207.1159156261115.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rename Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
------------------------------------------------------------------------------

                 Key: JBCACHE-782
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-782
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: 2.0.0


As agreed, we will rename this from useInterceptorMbeans to useMbean in Configuration. This flag will represent the generic JMX flag.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 23:51:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 23:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-782) Rename
 Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
In-Reply-To: <20747207.1159156261115.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32763577.1159156261221.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-782?page=all ]

Ben Wang resolved JBCACHE-782.
------------------------------

    Resolution: Done

> Rename Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-782
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-782
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> As agreed, we will rename this from useInterceptorMbeans to useMbean in Configuration. This flag will represent the generic JMX flag.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:09:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 25 Sep 2006 01:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-9) Mavenize Security
	Build
In-Reply-To: <24504065.1158609301211.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18341006.1159160941201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-9?page=all ]

Anil Saldhana closed SECURITY-9.
--------------------------------

    Resolution: Done

First cut of maven pom.xml checked in.

The requisite jars are created in output/lib

As and when we obtain additional expertise in Maven2, cleanup/optmization etc can be done.

> Mavenize Security Build
> -----------------------
>
>                 Key: SECURITY-9
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-9
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> Need to convert the security build into a maven based build.
> Reference:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation
> https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:09:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 25 Sep 2006 01:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-9) Mavenize Security
	Build
In-Reply-To: <24504065.1158609301211.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5304641.1159160941398.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/SECURITY-9?page=comments#action_12343917 ] 
            
Anil Saldhana commented on SECURITY-9:
--------------------------------------

Forum Thread:http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90069

> Mavenize Security Build
> -----------------------
>
>                 Key: SECURITY-9
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-9
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> Need to convert the security build into a maven based build.
> Reference:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation
> https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:46:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 25 Sep 2006 01:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-783) PojoCache to
 provide MBean interfaces
Message-ID: <19815578.1159163161304.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to provide MBean interfaces
-------------------------------------

                 Key: JBCACHE-783
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-783
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


In 2.0 release, since we are using delegation model for the core Cache, we can't no more rely on the underlying Cache to provide MBean interfaces. Instead, we are following the methodolody used in Cache. That is, we will have a .jmx.PojoCache class that has implemented the MBean interfaces and provide monitoring stats.

We will share the flag useMbean in Configuration object to activate MBean service.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:46:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 25 Sep 2006 01:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-783) PojoCache to
 provide MBean interfaces
In-Reply-To: <19815578.1159163161304.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30222126.1159163161411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-783?page=all ]

Ben Wang resolved JBCACHE-783.
------------------------------

    Resolution: Done

> PojoCache to provide MBean interfaces
> -------------------------------------
>
>                 Key: JBCACHE-783
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-783
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> In 2.0 release, since we are using delegation model for the core Cache, we can't no more rely on the underlying Cache to provide MBean interfaces. Instead, we are following the methodolody used in Cache. That is, we will have a .jmx.PojoCache class that has implemented the MBean interfaces and provide monitoring stats.
> We will share the flag useMbean in Configuration object to activate MBean service.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 02:48:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Mon, 25 Sep 2006 02:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-355) Constructor
 injection of component dependencies
In-Reply-To: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14969998.1159166881312.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-355?page=comments#action_12343918 ] 
            
Christian Bauer commented on JBSEAM-355:
----------------------------------------

I think we already have everything to do that by the way:

@Entity
@Table(name = "BID")
@org.hibernate.annotations.Entity(mutable = false)
@Name("bid")
public class Bid implements Serializable {
    ...
    /**
     * No-arg constructor for JavaBean tools.
     */
    public Bid() {}

    /**
     * Full constructor.
     *
     * @param amount
     * @param item
     * @param bidder
     */

    @Role(name="newBid", scope = ScopeType.CONVERSATION)
    public Bid(BigDecimal amount, @In Item item, @In("currentUser") User bidder) {
        this.amount = amount;
        this.item = item;
        this.bidder = bidder;
    }
    ...
}

> Constructor injection of component dependencies
> -----------------------------------------------
>
>                 Key: JBSEAM-355
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Minor
>
> Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 
> Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.
> Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:27:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-325) task priority not set
	properly
Message-ID: <22629505.1159169221167.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-325?page=all ]

Tom Baeyens closed JBPM-325.
----------------------------

    Resolution: Done

> task priority not set properly
> ------------------------------
>
>                 Key: JBPM-325
>                 URL: http://jira.jboss.com/jira/browse/JBPM-325
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:30:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-716) make the timer duedate
	optional
In-Reply-To: <16381613.1154586971316.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22832873.1159169401667.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-716?page=all ]

Tom Baeyens closed JBPM-716.
----------------------------

    Resolution: Done

> make the timer duedate optional
> -------------------------------
>
>                 Key: JBPM-716
>                 URL: http://jira.jboss.com/jira/browse/JBPM-716
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>            Priority: Minor
>             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1
>
>
> now, it's not possible to have a timer without a dueDate.  if we add a nullpointercheck, users can associate an action with the timer that fills in the dueDate programmatically.
> in org.jbpm.scheduler.def.CreateTimerAction a nullpointercheck should be added to the following two lines in the createTimer method :
>     Duration duration = new Duration(dueDate);
>     Date dueDate = businessCalendar.add( new Date(), duration );

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:36:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPM-434) Transitionname
 should be used even if there is just one
Message-ID: <5068964.1159169761724.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-434?page=all ]

Tom Baeyens reassigned JBPM-434:
--------------------------------

    Assignee: Koen Aers  (was: Ronald van Kuijk)

This could be part of the first default proposal that is shown when generating a task form.

> Transitionname should be used even if there is just one
> -------------------------------------------------------
>
>                 Key: JBPM-434
>                 URL: http://jira.jboss.com/jira/browse/JBPM-434
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Web Interface
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>            Priority: Optional
>             Fix For: jBPM 3.2 alpha 1
>
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> By default a 'save and close' is shown. Besides i18n this, I think by default the chosen transitionname should be used (maybe unless it is tr1 ;-) )

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:39:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-434) Transitionname should
 be used even if there is just one
Message-ID: <21690368.1159169941180.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-434?page=all ]

Tom Baeyens updated JBPM-434:
-----------------------------

    Component/s: Graphical Process Designer
                     (was: Web Interface)

> Transitionname should be used even if there is just one
> -------------------------------------------------------
>
>                 Key: JBPM-434
>                 URL: http://jira.jboss.com/jira/browse/JBPM-434
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Graphical Process Designer
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>            Priority: Optional
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> By default a 'save and close' is shown. Besides i18n this, I think by default the chosen transitionname should be used (maybe unless it is tr1 ;-) )

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:39:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-434) Transitionname should
 be used even if there is just one
Message-ID: <2450615.1159169941365.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-434?page=all ]

Tom Baeyens updated JBPM-434:
-----------------------------

    Fix Version/s:     (was: jBPM 3.2 alpha 1)

> Transitionname should be used even if there is just one
> -------------------------------------------------------
>
>                 Key: JBPM-434
>                 URL: http://jira.jboss.com/jira/browse/JBPM-434
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Graphical Process Designer
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>            Priority: Optional
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> By default a 'save and close' is shown. Besides i18n this, I think by default the chosen transitionname should be used (maybe unless it is tr1 ;-) )

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:04:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3612) failing
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <23206066.1157137423945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19848006.1159171441631.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3612?page=all ]

Dimitris Andreadis updated JBAS-3612:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> ----------------------------------------------------------------------
>
>                 Key: JBAS-3612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3612
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> test402Compatibility Failure
> Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.proxy.ClientContainerEx,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
> org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.monitor.alarm.AlarmNotification,
> org.jboss.monitor.alarm.AlarmTableNotification,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:06:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3613) failing test in
 org.jboss.test.iiop.test.ParameterPassingStressTestCase
In-Reply-To: <18562400.1157137544244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9710669.1159171561606.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3613?page=all ]

Dimitris Andreadis updated JBAS-3613:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3613
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3613
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-4.0.6.CR1
>
>
> test_getException Error
> Invalid indirection to offset 1704
> java.io.IOException: Invalid indirection to offset 1704
> 	at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
> 	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
> 	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
> 	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
> 	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.read_Array(ValueHandlerImpl.java:756)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:325)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
> 	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
> 	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
> 	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
> 	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:1989)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2213)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
> 	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
> 	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
> 	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
> 	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2310)
> 	at org.jacorb.orb.Any.read_value(Any.java:816)
> 	at org.jacorb.orb.CDRInputStream.read_any(CDRInputStream.java:673)
> 	at com.sun.corba.se.impl.javax.rmi.CORBA.Util.readAny(Util.java:401)
> 	at javax.rmi.CORBA.Util.readAny(Util.java:92)
> 	at org.jboss.iiop.rmi.marshal.CDRStream$ObjectReader.read(CDRStream.java:618)
> 	at org.jboss.iiop.rmi.marshal.strategy.StubStrategy.readRetval(StubStrategy.java:226)
> 	at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:128)
> 	at org.jboss.test.iiop.interfaces._StatelessSession_Stub.getException(Unknown Source)
> 	at org.jboss.test.iiop.test.ParameterPassingStressTestCase.test_getException(ParameterPassingStressTestCase.java:355)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:06:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3614) failing
 org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
In-Reply-To: <5797013.1157137545169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8230784.1159171561727.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3614?page=all ]

Dimitris Andreadis updated JBAS-3614:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3614
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3614
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testRMMResourceImplementsMBean Failure
> testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> junit.framework.AssertionFailedError: testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> 	at org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase.testRMMResourceImplementsMBean(ModelMBeanTestCase.java:150)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3615) failing test in
 org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
In-Reply-To: <10850104.1157137663981.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25104801.1159171741414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3615?page=all ]

Dimitris Andreadis updated JBAS-3615:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing test in org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-3615
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3615
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testMalformed Failure
> invalid object name: domain:=,foo=bar
> junit.framework.AssertionFailedError: invalid object name: domain:=,foo=bar
> 	at org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase$FullNameTEST.testMalformed(MalformedTestCase.java:152)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3616) failing test
 org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
In-Reply-To: <29398985.1157137784152.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28380281.1159171741532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3616?page=all ]

Dimitris Andreadis updated JBAS-3616:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing test org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
> -----------------------------------------------------------
>
>                 Key: JBAS-3616
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3616
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testMBeanInfoMarshalling Failure
> Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
> junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
> 	at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3617) 3 failing tests in
 org.jboss.test.util.test.PropertyEditorsUnitTestCase
In-Reply-To: <15495472.1157137904044.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7869347.1159171741644.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3617?page=all ]

Dimitris Andreadis updated JBAS-3617:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> 3 failing tests in org.jboss.test.util.test.PropertyEditorsUnitTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3617
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3617
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testEditorSearchPath Failure
> Found org.jboss.util.propertyeditor in search path
> junit.framework.AssertionFailedError: Found org.jboss.util.propertyeditor in search path
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testEditorSearchPath(PropertyEditorsUnitTestCase.java:127)
> testJavaLangEditors Failure
> Found property editor for: class java.lang.Boolean
> junit.framework.AssertionFailedError: Found property editor for: class java.lang.Boolean
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJavaLangEditors(PropertyEditorsUnitTestCase.java:188)
> testJBossEditors Failure
> Found property editor for: class javax.management.ObjectName
> junit.framework.AssertionFailedError: Found property editor for: class javax.management.ObjectName
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJBossEditors(PropertyEditorsUnitTestCase.java:306)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3611) Get the
 jboss-4.0-testsuite-sun-1.5 passing
In-Reply-To: <20914255.1157137303968.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8221991.1159171741765.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3611?page=all ]

Dimitris Andreadis updated JBAS-3611:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Fix the sun 1.5 testsuite in the next release. Focus on the sun/bea 1.4 testsuite runs and the OOMEs for the 4.0.5.GA release.

> Get the jboss-4.0-testsuite-sun-1.5 passing
> -------------------------------------------
>
>                 Key: JBAS-3611
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3611
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Container task for sun jdk1.5 test run failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:21:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Mon, 25 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3691) NoClassDefFoundError
 performing remote lookup of dynamic proxy using IBM JDK
Message-ID: <13932567.1159172461130.JavaMail.jira@cloud.prod.atl2.jboss.com>

NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK
----------------------------------------------------------------------------

                 Key: JBAS-3691
                 URL: http://jira.jboss.com/jira/browse/JBAS-3691
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.4.GA
         Environment: IBM JDK 1.5 32bit and 64bit
IBM JDK 1.4 64bit
            Reporter: Darran Lofthouse
         Assigned To: Darran Lofthouse
             Fix For: JBossAS-4.0.6.CR1


Using the IBM JDKs listed in the environment, performing a remote lookup of a dynamic proxy from within JBoss cases a NoClassDefFoundError.



-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:21:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Mon, 25 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3691) NoClassDefFoundError
 performing remote lookup of dynamic proxy using IBM JDK
In-Reply-To: <13932567.1159172461130.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25849834.1159172461251.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3691?page=all ]

Darran Lofthouse updated JBAS-3691:
-----------------------------------

    Component/s: ClassLoading

> NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3691
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3691
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: IBM JDK 1.5 32bit and 64bit
> IBM JDK 1.4 64bit
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Using the IBM JDKs listed in the environment, performing a remote lookup of a dynamic proxy from within JBoss cases a NoClassDefFoundError.

-- 
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

        


From c14 at fullmailmarket.com  Mon Sep 25 04:57:54 2006
From: c14 at fullmailmarket.com (Carrier 179)
Date: Mon, 25 Sep 2006 04:57:54 -0400
Subject: [jboss-jira] =?iso-8859-1?q?Compare_y_se_convencer=E1!_?=
Message-ID: <200609250857.k8P8vtr8013790@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060925/8fa468dc/attachment.html 

From jira-events at jboss.com  Mon Sep 25 05:27:35 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 05:27:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-80) consistent naming
	for jars
Message-ID: <22630014.1159176455961.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-80?page=comments#action_12343923 ] 
            
Kevin Conner commented on JBTM-80:
----------------------------------

In that case it should be the others as jbossts-common is shared between jts and jta and should not be named after either of them.

A better shceme would be to change the others to the following

jbossts-jta.jar
jbossts-jta-integration.jar
jbossts-jts.jar
jbossts-jts-integration.jar
jbossts-jts-jacorb.jar


> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 05:33:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 25 Sep 2006 05:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-80) consistent naming
	for jars
Message-ID: <29350056.1159176781089.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-80?page=comments#action_12343924 ] 
            
Mark Little commented on JBTM-80:
---------------------------------

Sure that's fine: it's consistent ;-)

> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:06:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7338944.1159178761203.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3597?page=comments#action_12343928 ] 
            
Dimitris Andreadis commented on JBAS-3597:
------------------------------------------

Client
3.2.8.SP1

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.6.CR1
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13592026.1159178941201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis updated JBAS-3437:
-------------------------------------

          Summary: Get the 3.2-compatibility tests passing for 4.0.6.CR1  (was: Get the 3.2-compatibility tests passing for 4.0.5.GA)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

There is no intention to fix the transient failures in the subtask for 4.0.5.GA

> Get the 3.2-compatibility tests passing for 4.0.6.CR1
> -----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.6.CR1
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13613903.1159178941328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis reassigned JBAS-3437:
----------------------------------------

    Assignee:     (was: Dimitris Andreadis)

> Get the 3.2-compatibility tests passing for 4.0.6.CR1
> -----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3228) Enable browsing of
 scheduled messages
Message-ID: <29941712.1159179301269.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3228?page=all ]

Adrian Brock closed JBAS-3228.
------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                   JBossAS-5.0.0.Beta
       Resolution: Done

See:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigQueue
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigTopic

> Enable browsing of scheduled messages
> -------------------------------------
>
>                 Key: JBAS-3228
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3228
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> We have a requirement to check the messages that are currently scheduled to deliver but not yet in the queue. 
> "ScheduledMessageCount" denotes the total number of scheduled messages. As far as I know, queue brower 
> only works with messages in the queue, so how to browse those scheduled messages? This is typically 
> more important than queued messages since they may be failed and reschduled ones. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3386) Expose "in process"
 messages via JMX
In-Reply-To: <33373175.1152715572226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27623785.1159179301463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3386?page=all ]

Adrian Brock closed JBAS-3386.
------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                   JBossAS-5.0.0.Beta
       Resolution: Done

See:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigQueue
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigTopic

> Expose "in process" messages via JMX
> ------------------------------------
>
>                 Key: JBAS-3386
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3386
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> Expose the number of "in process" (i.e. unacknowledged messages given to the client)
> via the JMX interfaces.
> e.g. change 
> org.jboss.mq.server.jmx.Queue to have
> public int getInProcessCount()
> {
>    return jmsQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.JMSQueue to have
> public int getInProcessCount()
> {
>    return basicQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.BasicQueue to have
> public int getInProcessCount()
> {
>    return unacknowledgeMessages.size(); 
> }

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3665) Update JBoss
 Serialization to 1.0.3.GA
In-Reply-To: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19187677.1159179301986.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3665?page=all ]

Dimitris Andreadis updated JBAS-3665:
-------------------------------------

    Summary: Update JBoss Serialization to 1.0.3.GA  (was: Update JBoss Serialization)

> Update JBoss Serialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBAS-3665
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3386) Expose "in process"
 messages via JMX
In-Reply-To: <33373175.1152715572226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11516209.1159179302114.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3386?page=all ]

Adrian Brock reassigned JBAS-3386:
----------------------------------

    Assignee: Adrian Brock

> Expose "in process" messages via JMX
> ------------------------------------
>
>                 Key: JBAS-3386
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3386
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Expose the number of "in process" (i.e. unacknowledged messages given to the client)
> via the JMX interfaces.
> e.g. change 
> org.jboss.mq.server.jmx.Queue to have
> public int getInProcessCount()
> {
>    return jmsQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.JMSQueue to have
> public int getInProcessCount()
> {
>    return basicQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.BasicQueue to have
> public int getInProcessCount()
> {
>    return unacknowledgeMessages.size(); 
> }

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3228) Enable browsing of
 scheduled messages
Message-ID: <20795662.1159179302287.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3228?page=all ]

Adrian Brock reassigned JBAS-3228:
----------------------------------

    Assignee: Adrian Brock

> Enable browsing of scheduled messages
> -------------------------------------
>
>                 Key: JBAS-3228
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3228
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> We have a requirement to check the messages that are currently scheduled to deliver but not yet in the queue. 
> "ScheduledMessageCount" denotes the total number of scheduled messages. As far as I know, queue brower 
> only works with messages in the queue, so how to browse those scheduled messages? This is typically 
> more important than queued messages since they may be failed and reschduled ones. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:24:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3582) Get the ejb3-4.0
 testsuite passing
In-Reply-To: <28677268.1156859718767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12611351.1159179841341.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3582?page=all ]

Dimitris Andreadis updated JBAS-3582:
-------------------------------------

    Comment: was deleted

> Get the ejb3-4.0 testsuite passing
> ----------------------------------
>
>                 Key: JBAS-3582
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3582
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> There are currenlty 28 failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:24:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3582) Get the ejb3-4.0
 testsuite passing
In-Reply-To: <28677268.1156859718767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20378073.1159179841520.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3582?page=comments#action_12343935 ] 
            
Dimitris Andreadis commented on JBAS-3582:
------------------------------------------

We are at a constant 22 erros failing:

http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite

If you do not intend to work on those failures this week, please reschedule for the next release.

> Get the ejb3-4.0 testsuite passing
> ----------------------------------
>
>                 Key: JBAS-3582
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3582
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> There are currenlty 28 failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
In-Reply-To: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30215329.1159180021351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-127?page=all ]

Kevin Conner closed JBTM-127.
-----------------------------


> UID must befine a value for the maximum UID and enforce the ordering during comparison.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBTM-127
>                 URL: http://jira.jboss.com/jira/browse/JBTM-127
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.
> UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-126) JTS XATerminator
 references arjunacore classes
In-Reply-To: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27659863.1159180021477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-126?page=all ]

Kevin Conner closed JBTM-126.
-----------------------------


> JTS XATerminator references arjunacore classes
> ----------------------------------------------
>
>                 Key: JBTM-126
>                 URL: http://jira.jboss.com/jira/browse/JBTM-126
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-125) The transaction manager
 implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
In-Reply-To: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19364528.1159180021593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-125?page=all ]

Kevin Conner closed JBTM-125.
-----------------------------


> The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-125
>                 URL: http://jira.jboss.com/jira/browse/JBTM-125
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-124) atsintegration must
 have its own logging
In-Reply-To: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30581435.1159180021714.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-124?page=all ]

Kevin Conner closed JBTM-124.
-----------------------------


> atsintegration must have its own logging
> ----------------------------------------
>
>                 Key: JBTM-124
>                 URL: http://jira.jboss.com/jira/browse/JBTM-124
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-84) The Xid implementation
 should implement the hashCode and equals methods from Object
Message-ID: <21576829.1159180021869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-84?page=all ]

Kevin Conner closed JBTM-84.
----------------------------


> The Xid implementation should implement the hashCode and equals methods from Object
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-84
>                 URL: http://jira.jboss.com/jira/browse/JBTM-84
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> XidImpl does not implement the equals and hashCode methods.  This prevents Xid being used in hash maps/sets.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-83) Multiple recovery
 threads get initialised when embedded in the application server
Message-ID: <22518653.1159180022037.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-83?page=all ]

Kevin Conner closed JBTM-83.
----------------------------


> Multiple recovery threads get initialised when embedded in the application server
> ---------------------------------------------------------------------------------
>
>                 Key: JBTM-83
>                 URL: http://jira.jboss.com/jira/browse/JBTM-83
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>         Attachments: jbossjta-integration.jar, jbossjts-integration.jar
>
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>
> The TransactionManagerServiceMBean implementations initialise the recovery manager directly instead of using the singleton.  The result of this is that the recovery manager is initialised twice, when other code calls the singleton, and two recovery threads are subsequently created.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-78) JTA installation does
 not include the XARecoveryModule
Message-ID: <16335546.1159180022170.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-78?page=all ]

Kevin Conner closed JBTM-78.
----------------------------


> JTA installation does not include the XARecoveryModule
> ------------------------------------------------------
>
>                 Key: JBTM-78
>                 URL: http://jira.jboss.com/jira/browse/JBTM-78
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The properrties file included in the JTA distribution does not include the XARecoveryModule

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-67) The installation notes
 incorrectly specify the initialisation of both TS interceptors.
Message-ID: <33012373.1159180022314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-67?page=all ]

Kevin Conner closed JBTM-67.
----------------------------


> The installation notes incorrectly specify the initialisation of both TS interceptors.
> --------------------------------------------------------------------------------------
>
>                 Key: JBTM-67
>                 URL: http://jira.jboss.com/jira/browse/JBTM-67
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> The installation notes incorrectly specify the initialisation of both the standard context interceptor and the interposition interceptor.  These interceptors are mutually exclusive.
> The symptom exhibited by this problem is OutOfMemoryErrors being logged to the standard output.  This occurs because the interposition interceptor incorrectly interprets part of a text string as a length (approx 1GB).

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:30:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <7289705.1159180201279.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-87?page=comments#action_12343936 ] 
            
Kevin Conner commented on JBTM-87:
----------------------------------

The LRCO functionality has been added back in revision 6409

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:42:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3665) Update JBoss
 Serialization to 1.0.3.GA
In-Reply-To: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28972585.1159180921382.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3665?page=all ]

Dimitris Andreadis closed JBAS-3665.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis  (was: Clebert Suconic)

Updated build-thirdparty.xml, seems ok.

> Update JBoss Serialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBAS-3665
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:42:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <2529709.1159180921602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-87?page=all ]

Kevin Conner resolved JBTM-87.
------------------------------

    Fix Version/s: 4.2.2
       Resolution: Done

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:42:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <16085138.1159180921776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-87?page=all ]

Kevin Conner closed JBTM-87.
----------------------------


> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:48:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12922252.1159181281980.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343938 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

Fixed in revision 6410


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:48:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12324595.1159181282174.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-116?page=all ]

Kevin Conner resolved JBTM-116.
-------------------------------

    Resolution: Done

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:48:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13800503.1159181282340.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-116?page=all ]

Kevin Conner closed JBTM-116.
-----------------------------


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:54:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-81) Delay start of
	recovery manager
Message-ID: <26185830.1159181641393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-81?page=all ]

Kevin Conner resolved JBTM-81.
------------------------------

    Resolution: Done

Fixed in revision 6408

> Delay start of recovery manager
> -------------------------------
>
>                 Key: JBTM-81
>                 URL: http://jira.jboss.com/jira/browse/JBTM-81
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace:
> 10:52:35,529 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\
> l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource
> java.io.StreamCorruptedException: unexpected end of block data
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\
> Module.java:178)
> This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:54:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-81) Delay start of recovery
	manager
Message-ID: <17085093.1159181641563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-81?page=all ]

Kevin Conner closed JBTM-81.
----------------------------


> Delay start of recovery manager
> -------------------------------
>
>                 Key: JBTM-81
>                 URL: http://jira.jboss.com/jira/browse/JBTM-81
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace:
> 10:52:35,529 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\
> l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource
> java.io.StreamCorruptedException: unexpected end of block data
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\
> Module.java:178)
> This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:12:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-130) Validation of timeout
 values before calling the reaper
Message-ID: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validation of timeout values before calling the reaper
------------------------------------------------------

                 Key: JBTM-130
                 URL: http://jira.jboss.com/jira/browse/JBTM-130
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:21:01 2006
From: jira-events at jboss.com (James Hickey (JIRA))
Date: Mon, 25 Sep 2006 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-784) "Random"
 TimeoutException occurs after CacheLoader get() returns
Message-ID: <5715269.1159183261505.JavaMail.jira@cloud.prod.atl2.jboss.com>

"Random" TimeoutException occurs after CacheLoader get() returns
----------------------------------------------------------------

                 Key: JBCACHE-784
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-784
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 1.4.0
         Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1 instances (pessimistic locking), no eviction policy
            Reporter: James Hickey
         Assigned To: Manik Surtani


We experience a strange issue which happens every so often whereby shortly after one of our replicated cache instances calls it's CacheLoader.get() to populate a particular FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the scenario/stack trace follows:

The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's get() method successfully returns (can see this as we have debugging in the cache loader). Subsequent calls are instantaneously successful and do not result in  a further call to the cacheloader.

It looks to me like it could possibly be some kind of tx/locking/thread contention issue, as it happens more often than not where we have approx 10-20 threads which have all resulted in a call to the cache loader in a short space of time.

Any advice/opinion would be appreciated

Thanks
James

org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted at 10e4fd3)
        at org.jboss.cache.Node.acquire(Node.java:407)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
        at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
        at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3453)


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-130) Validation of
 timeout values before calling the reaper
In-Reply-To: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32126522.1159183981226.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-130?page=comments#action_12343943 ] 
            
Kevin Conner commented on JBTM-130:
-----------------------------------

Fixed in revision 6411.

> Validation of timeout values before calling the reaper
> ------------------------------------------------------
>
>                 Key: JBTM-130
>                 URL: http://jira.jboss.com/jira/browse/JBTM-130
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-130) Validation of
 timeout values before calling the reaper
In-Reply-To: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15880423.1159183981352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-130?page=all ]

Kevin Conner resolved JBTM-130.
-------------------------------

    Resolution: Done

> Validation of timeout values before calling the reaper
> ------------------------------------------------------
>
>                 Key: JBTM-130
>                 URL: http://jira.jboss.com/jira/browse/JBTM-130
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20541291.1159183981805.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3651?page=all ]

Dimitris Andreadis reassigned JBAS-3651:
----------------------------------------

    Assignee: Ryan Campbell  (was: Dimitris Andreadis)

Ryan, could you assign this to somebody that would record testsuite failures on Solaris10?

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Ryan Campbell
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-130) Validation of timeout
 values before calling the reaper
In-Reply-To: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23410919.1159183981918.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-130?page=all ]

Kevin Conner closed JBTM-130.
-----------------------------


> Validation of timeout values before calling the reaper
> ------------------------------------------------------
>
>                 Key: JBTM-130
>                 URL: http://jira.jboss.com/jira/browse/JBTM-130
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-131) XidImple requires
	serialVersionUID
Message-ID: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>

XidImple requires serialVersionUID
----------------------------------

                 Key: JBTM-131
                 URL: http://jira.jboss.com/jira/browse/JBTM-131
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Kevin Conner
         Assigned To: Mark Little


The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-131) XidImple requires
 serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13520682.1159184341601.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-131?page=all ]

Kevin Conner reassigned JBTM-131:
---------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-131) XidImple requires
 serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10623317.1159184342135.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-131?page=comments#action_12343945 ] 
            
Kevin Conner commented on JBTM-131:
-----------------------------------

Fixed in revision 6412.

> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-131) XidImple requires
 serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1380500.1159184342264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-131?page=all ]

Kevin Conner resolved JBTM-131.
-------------------------------

    Resolution: Done

> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:42:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-131) XidImple requires
	serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14391330.1159184521336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-131?page=all ]

Kevin Conner closed JBTM-131.
-----------------------------


> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:42:02 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 07:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3071) MemoryLeak
 (redeployment) on EJB3
Message-ID: <24708401.1159184522559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ]

Dimitris Andreadis reassigned JBAS-3071:
----------------------------------------

    Assignee: Emmanuel Bernard  (was: Bill Burke)

> MemoryLeak (redeployment) on EJB3
> ---------------------------------
>
>                 Key: JBAS-3071
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Emmanuel Bernard
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> This might be caused by JBAS-3016:
> But I'm seeing this strong reference:
> org.jboss.mx.loading.UnifiedClassLoader3 at 33411906
> !--- org.jboss.ejb3.stateless.StatelessContainer at 29610827
> We should make sure EJB3 packages are not leaking.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:57:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 07:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3693) Other XAResource
	errors
Message-ID: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>

Other XAResource errors
-----------------------

                 Key: JBAS-3693
                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Adrian Brock
         Assigned To: Weston Price
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


Further to JBAS-3336 (resource manager error during error should close the connection). 

There are other xa resource failures that need to be catered for.
e.g. a failure to delist probably means a probably means a problem with the connection.

Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection

   public void end(Xid xid, int flags) throws XAException
   {
+      try
+      {
         xaResource.end(xid, flags);
+      }
+      catch (XAException e)
+      {
+          broadcastConnectionError(e);
+          throw e;
+      }
...


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 08:00:01 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Mon, 25 Sep 2006 08:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3676) Upgrade
 jboss-common to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7907674.1159185601239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3676?page=comments#action_12343946 ] 
            
Thomas Diesler commented on JBAS-3676:
--------------------------------------

What is the SVN branch for this? 
I need to check if my changes are going to make it in 4.0.5

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Mon Sep 25 08:03:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 08:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3676) Upgrade
 jboss-common to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15430107.1159185781042.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3676?page=comments#action_12343947 ] 
            
Dimitris Andreadis commented on JBAS-3676:
------------------------------------------

Hi Thomas, it's here:

https://svn.jboss.org/repos/common/common-old/branches/Branch_1_0/

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Mon Sep 25 08:06:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 08:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18143872.1159185961289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3693?page=all ]

Adrian Brock updated JBAS-3693:
-------------------------------

    Description: 
Further to JBAS-3336 (resource manager error during enlist should close the connection). 

There are other xa resource failures that need to be catered for.
e.g. a failure to delist probably means a problem with the connection.

Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection

   public void end(Xid xid, int flags) throws XAException
   {
+      try
+      {
         xaResource.end(xid, flags);
+      }
+      catch (XAException e)
+      {
+          broadcastConnectionError(e);
+          throw e;
+      }
...


  was:
Further to JBAS-3336 (resource manager error during error should close the connection). 

There are other xa resource failures that need to be catered for.
e.g. a failure to delist probably means a probably means a problem with the connection.

Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection

   public void end(Xid xid, int flags) throws XAException
   {
+      try
+      {
         xaResource.end(xid, flags);
+      }
+      catch (XAException e)
+      {
+          broadcastConnectionError(e);
+          throw e;
+      }
...



> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 08:54:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 25 Sep 2006 08:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-148) Glossary of terms
Message-ID: <28492607.1159188841189.JavaMail.jira@cloud.prod.atl2.jboss.com>

Glossary of terms
-----------------

                 Key: JBESB-148
                 URL: http://jira.jboss.com/jira/browse/JBESB-148
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


We need a glossary of terms in the documentation and/or wiki.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:16:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-132) Incorrect Uid values
 used in JTA/JTS XAResourceRecord
Message-ID: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>

Incorrect Uid values used in JTA/JTS XAResourceRecord
-----------------------------------------------------

                 Key: JBTM-132
                 URL: http://jira.jboss.com/jira/browse/JBTM-132
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.

The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-132) Incorrect Uid
 values used in JTA/JTS XAResourceRecord
In-Reply-To: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16128490.1159190461138.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-132?page=comments#action_12343952 ] 
            
Kevin Conner commented on JBTM-132:
-----------------------------------

Fixed in revision 6414.

> Incorrect Uid values used in JTA/JTS XAResourceRecord
> -----------------------------------------------------
>
>                 Key: JBTM-132
>                 URL: http://jira.jboss.com/jira/browse/JBTM-132
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.
> The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-132) Incorrect Uid values
 used in JTA/JTS XAResourceRecord
In-Reply-To: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3310730.1159190461247.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-132?page=all ]

Kevin Conner resolved JBTM-132.
-------------------------------

    Resolution: Done

> Incorrect Uid values used in JTA/JTS XAResourceRecord
> -----------------------------------------------------
>
>                 Key: JBTM-132
>                 URL: http://jira.jboss.com/jira/browse/JBTM-132
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.
> The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-132) Incorrect Uid values
 used in JTA/JTS XAResourceRecord
In-Reply-To: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12329627.1159190461396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-132?page=all ]

Kevin Conner closed JBTM-132.
-----------------------------


> Incorrect Uid values used in JTA/JTS XAResourceRecord
> -----------------------------------------------------
>
>                 Key: JBTM-132
>                 URL: http://jira.jboss.com/jira/browse/JBTM-132
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.
> The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:43:02 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Mon, 25 Sep 2006 09:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3071) MemoryLeak
 (redeployment) on EJB3
Message-ID: <22232286.1159191782189.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ]

Emmanuel Bernard reassigned JBAS-3071:
--------------------------------------

    Assignee: Bill Burke  (was: Emmanuel Bernard)

I'm removing my assignment.
My part has been fixed but I see things on the Timer and the ThreadLocal, reassigning to Bill so that he can dispatch to someone else.

> MemoryLeak (redeployment) on EJB3
> ---------------------------------
>
>                 Key: JBAS-3071
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> This might be caused by JBAS-3016:
> But I'm seeing this strong reference:
> org.jboss.mx.loading.UnifiedClassLoader3 at 33411906
> !--- org.jboss.ejb3.stateless.StatelessContainer at 29610827
> We should make sure EJB3 packages are not leaking.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:45:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-127) Eliminate all GPL
 dependencies from the new forums
Message-ID: <17804893.1159191901022.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eliminate all GPL dependencies from the new forums
--------------------------------------------------

                 Key: JBFORUMS-127
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-127
             Project: JBoss Forums
          Issue Type: Task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 1.1.0 Alpha


Need to identify any GPL dependencies and convert to LGPL

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:47:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-128) Need to remove
 the phpBB graphics with our own
Message-ID: <31271635.1159192021233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Need to remove the phpBB graphics with our own
----------------------------------------------

                 Key: JBFORUMS-128
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-128
             Project: JBoss Forums
          Issue Type: Sub-task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: James Cobb
             Fix For: 1.1.0 Alpha




-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:47:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-128) Need to remove
 the phpBB graphics and replace with our own
In-Reply-To: <31271635.1159192021233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15415731.1159192021390.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-128?page=all ]

Sohil Shah updated JBFORUMS-128:
--------------------------------

    Summary: Need to remove the phpBB graphics and replace with our own  (was: Need to remove the phpBB graphics with our own)

> Need to remove the phpBB graphics and replace with our own
> ----------------------------------------------------------
>
>                 Key: JBFORUMS-128
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-128
>             Project: JBoss Forums
>          Issue Type: Sub-task
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: James Cobb
>             Fix For: 1.1.0 Alpha
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:47:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-129) Modify the schema
 being used from PHPBB
Message-ID: <31925238.1159192021505.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify the schema being used from PHPBB
---------------------------------------

                 Key: JBFORUMS-129
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-129
             Project: JBoss Forums
          Issue Type: Sub-task
            Reporter: Sohil Shah
         Assigned To: Sohil Shah




-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:50:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-129) Modify the
 schema being used from PHPBB
In-Reply-To: <31925238.1159192021505.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31354938.1159192201598.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-129?page=comments#action_12343954 ] 
            
Sohil Shah commented on JBFORUMS-129:
-------------------------------------

Also make sure once the schema is modified,

corresponding changes are made in the Hibernate layer to accomodate the new schema. This should probably only require changing mapping files.


But will know more once the schema migration is started.


Also, test and make sure the Forums bussiness module plays nice with the new schema

> Modify the schema being used from PHPBB
> ---------------------------------------
>
>                 Key: JBFORUMS-129
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-129
>             Project: JBoss Forums
>          Issue Type: Sub-task
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 10:34:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 25 Sep 2006 10:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-329) Implement block() in
	Multiplexer
Message-ID: <31142280.1159194841184.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement block() in Multiplexer
--------------------------------

                 Key: JGRP-329
                 URL: http://jira.jboss.com/jira/browse/JGRP-329
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


Simple implementation: block all of the services on top of the same channel in the Multiplexer.

Does this potentially need a blockCompleted() callback ?

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 10:51:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22775771.1159195861332.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3693?page=comments#action_12343959 ] 
            
Weston Price commented on JBAS-3693:
------------------------------------

I should have done this before. I wondered about it. I'll get on it.

> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:00:02 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 11:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3183) Integration with
	WebSphere MQ 5.x
Message-ID: <12106327.1159196403003.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3183?page=all ]

Weston Price updated JBAS-3183:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Moving to 4.0.6

> Integration with WebSphere MQ 5.x
> ---------------------------------
>
>                 Key: JBAS-3183
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3183
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>         Environment: WebSphereMQ 5.3 with Extended TX client
>            Reporter: Luc Texier
>         Assigned To: Weston Price
>            Priority: Critical
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: mq-trace.jar, mq-xa.zip
>
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossASPart2
> we need to make some changes to StdServerSession and StdServerSessionPool to integrate two workarounds in order to properly integrate with WSMQ 5.x and support their XA resource implementation and transaction handling

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:09:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 11:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14246618.1159196941530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3690?page=all ]

Brian Stansberry updated JBAS-3690:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
         Assignee: Brian Stansberry

*If* it's a bug I'll fix it for 4.0.5.GA.

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:12:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3694) Activate MDB in a
	seperate thread
Message-ID: <1886851.1159197121304.JavaMail.jira@cloud.prod.atl2.jboss.com>

Activate MDB in a seperate thread
---------------------------------

                 Key: JBAS-3694
                 URL: http://jira.jboss.com/jira/browse/JBAS-3694
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock


There should be an option in the MDB startup (JMSContainerInvoker)
to activate the jms delivery on a separate thread such that a miss-behaving JMS
implementation does not block the main bootstrap thread.

This already exists in the new jms resource adapter inflow
where the connection to the jms server is executed via the work manager. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:18:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 11:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1434) JMS Message Inflow
Message-ID: <24339542.1159197481936.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1434?page=all ]

Weston Price updated JBAS-1434:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Being done in tandem with 3183. 

> JMS Message Inflow
> ------------------
>
>                 Key: JBAS-1434
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1434
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48672
> The JMS message inflow in the JMS resource adapter needs properly testing.
> There are basic tests, but the following are missing:
> 1) Complete tests of edge cases for each configuration parameter in the activation spec
> 2) Failure tests to confirm the implementation handles error gracefully
> 3) Stress tests to make sure there the implementation is stable
> 4) Performance tests to optimize the implementation
> Additionally, we need to confirm that it is possible to use this implementation for EJB2.0
> style deployments and hence as the default configuration. 
> This should be possible provided the user has not created their own
> container configuration that uses the old JMSContainerInvoker explicitly.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:27:06 2006
From: jira-events at jboss.com (Jason T. Greene (JIRA))
Date: Mon, 25 Sep 2006 11:27:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14342829.1159198026311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3678?page=all ]

Jason T. Greene reassigned JBAS-3678:
-------------------------------------

    Assignee: Ryan Campbell  (was: Jason T. Greene)

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Ryan Campbell
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:45:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-76) optimize unmarshalling
 of arrays of repeatable particles
In-Reply-To: <14684322.1154703492098.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22048116.1159199101540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-76?page=all ]

Alexey Loubyansky closed JBXB-76.
---------------------------------

    Fix Version/s: JBossXB-1.0.0.CR7
                       (was: JBossXB-1.0)
       Resolution: Done

Fixed.

> optimize unmarshalling of arrays of repeatable particles
> --------------------------------------------------------
>
>                 Key: JBXB-76
>                 URL: http://jira.jboss.com/jira/browse/JBXB-76
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>
> When an repeatable XSD term (element, model group or wildcard) is bound to a field of an array type, the current implementation acts inefficient.
> Each time the term is unmarshalled, the array which is the value of the field is recreated to add the just unmarshalled particle. Instead, repeatable terms should be recognized, the array items should be collected in a temp collection and the final array should be created when the last repeated term is unmarshalled.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:45:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-85) Add support for base64
 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16201814.1159199101740.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-85?page=all ]

Alexey Loubyansky closed JBXB-85.
---------------------------------

    Fix Version/s: JBossXB-1.0.0.CR7
       Resolution: Done

Fixed.

> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:45:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29497678.1159199101869.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3659?page=comments#action_12343967 ] 
            
Brian Stansberry commented on JBAS-3659:
----------------------------------------

I would doubt it.  This should result in an increase of about 2.3MB in memory used by the process (not heap memory; this is memory used by the underlying TCP subsystem.  Not sure what the problems you're seeing are; will respond separately to try to trace it down.

> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:54:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 11:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-37) Remove dependency on
 ObjectModelProvider in SchemaBinding-based marshaller
Message-ID: <20459759.1159199641361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-37?page=all ]

Alexey Loubyansky closed JBXB-37.
---------------------------------

    Resolution: Out of Date

It doesn't actually use it. But references in method signatures for historical reasons.

> Remove dependency on ObjectModelProvider in SchemaBinding-based marshaller
> --------------------------------------------------------------------------
>
>                 Key: JBXB-37
>                 URL: http://jira.jboss.com/jira/browse/JBXB-37
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>
> This marshaller should use binding metadata available in the SchemaBinding.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:57:01 2006
From: jira-events at jboss.com (jasonc411 (JIRA))
Date: Mon, 25 Sep 2006 11:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-503) Compiler Throwing
 an exception on generics
Message-ID: <23708343.1159199821228.JavaMail.jira@cloud.prod.atl2.jboss.com>

Compiler Throwing an exception on generics
------------------------------------------

                 Key: JBRULES-503
                 URL: http://jira.jboss.com/jira/browse/JBRULES-503
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions: 3.0.4
         Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
            Reporter: jasonc411
         Assigned To: Mark Proctor


#created on: Sep 15, 2006
package com.ca.data.dsrules

#list any import classes here.
import com.ca.data.model.base.DataSourceEnum;
import com.ca.data.model.issuer.Issuer;
import java.util.ArrayList;
import java.util.List;
import com.ca.data.model.Data;
import com.ca.data.datasubs.utils.JMSServiceLocator;
import com.ca.data.jms.JMSTextMessageSender;


function void save(Issuer issuer){
	JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
	Data data = new Data();
	List<Issuer> myIssuers = new ArrayList<Issuer>();
	myIssuers.add(issuer);
	
	Data.setIssuerList(myIssuers);
	
	cleanQueue.simpleSend(issuer);
}

rule "Persist Validated Data"
	agenda-group "Data In"
	no loop
	salience 1
	
	when
		issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
	then 
		System.out.println("Validated");
		save(issuer);
end

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:00:02 2006
From: jira-events at jboss.com (jasonc411 (JIRA))
Date: Mon, 25 Sep 2006 12:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-503) Compiler
 Throwing an exception on generics
In-Reply-To: <23708343.1159199821228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27009052.1159200002137.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-503?page=comments#action_12343970 ] 
            
jasonc411 commented on JBRULES-503:
-----------------------------------

When compiling the above file, I get the error:

2006-09-25 09:56:54,914 ERROR com.ca.data.controllers.issuer.PersistIssuer Unable to add processing rules, exception unspecified. 
org.drools.rule.InvalidRulePackage: Function Compilation error

        at org.drools.rule.Package.checkValidity(Unknown Source)
        at org.drools.common.AbstractRuleBase.addPackage(Unknown Source)


When I remove the line with the generic, it compiles fine.  Also there is no additional info other than exception unspecified.  

> Compiler Throwing an exception on generics
> ------------------------------------------
>
>                 Key: JBRULES-503
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-503
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.4
>         Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
>            Reporter: jasonc411
>         Assigned To: Mark Proctor
>
> #created on: Sep 15, 2006
> package com.ca.data.dsrules
> #list any import classes here.
> import com.ca.data.model.base.DataSourceEnum;
> import com.ca.data.model.issuer.Issuer;
> import java.util.ArrayList;
> import java.util.List;
> import com.ca.data.model.Data;
> import com.ca.data.datasubs.utils.JMSServiceLocator;
> import com.ca.data.jms.JMSTextMessageSender;
> function void save(Issuer issuer){
> 	JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
> 	Data data = new Data();
> 	List<Issuer> myIssuers = new ArrayList<Issuer>();
> 	myIssuers.add(issuer);
> 	
> 	Data.setIssuerList(myIssuers);
> 	
> 	cleanQueue.simpleSend(issuer);
> }
> rule "Persist Validated Data"
> 	agenda-group "Data In"
> 	no loop
> 	salience 1
> 	
> 	when
> 		issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
> 	then 
> 		System.out.println("Validated");
> 		save(issuer);
> end

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:03:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17800000.1159200181719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3690?page=all ]

Brian Stansberry resolved JBAS-3690.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Rejected

The test is fine.  JSESSIONIDSSO is the name of the cookie used for SSO.

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:06:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 12:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9618480.1159200361497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-79?page=all ]

Alexey Loubyansky updated JBXB-79:
----------------------------------

        Fix Version/s: JBossXB-1.0.0.CR7
    Affects Version/s: JBossXB-1.0.0.CR6

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:06:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 12:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-82) Release CR7 that
 aligns with AS 4.0.5.GA
In-Reply-To: <5411313.1158669716890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25275032.1159200361672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-82?page=all ]

Alexey Loubyansky updated JBXB-82:
----------------------------------

    Fix Version/s: JBossXB-1.0.0.CR7

> Release CR7 that aligns with AS 4.0.5.GA
> ----------------------------------------
>
>                 Key: JBXB-82
>                 URL: http://jira.jboss.com/jira/browse/JBXB-82
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>            Priority: Critical
>             Fix For: JBossXB-1.0.0.CR7
>
>
> JBossWS has a dependency on it.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:26:04 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3071) MemoryLeak
	(redeployment) on EJB3
Message-ID: <4298114.1159201564575.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ]

Dimitris Andreadis updated JBAS-3071:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Rescheduling

> MemoryLeak (redeployment) on EJB3
> ---------------------------------
>
>                 Key: JBAS-3071
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
> This might be caused by JBAS-3016:
> But I'm seeing this strong reference:
> org.jboss.mx.loading.UnifiedClassLoader3 at 33411906
> !--- org.jboss.ejb3.stateless.StatelessContainer at 29610827
> We should make sure EJB3 packages are not leaking.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:37:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 25 Sep 2006 12:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1056) Drag/Drop
 dropmarker for better user experience
In-Reply-To: <14908268.1158947101578.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18925673.1159202221093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1056?page=all ]

Roy Russo resolved JBPORTAL-1056.
---------------------------------

    Resolution: Done

> Drag/Drop dropmarker for better user experience
> -----------------------------------------------
>
>                 Key: JBPORTAL-1056
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1056
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3111) JBOSS does not
 release handle of log files even when logging is complete
Message-ID: <1132563.1159202941220.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3111?page=all ]

Dimitris Andreadis closed JBAS-3111.
------------------------------------

    Resolution: Rejected

I don't think this is a jboss issue, maybe a log4j one. If the logger is configured to use org.jboss.logging.appender.DailyRollingFileAppender, doen't that let you remove the older/renamed logs?

> JBOSS does not release handle of log files even when logging is complete
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3111
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3111
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>         Environment: Windows 2000/xp, J2SDK1.4.2.08
>            Reporter: shishir das
>
> JBOSS does not release log file handle even when logging is complete. So we cannot delete log files no longer needed unless we restart the jboss server. To elaborate the scenario Consider the following:- 
>  
> Suppose there is an web application. one of its engines run 5 times a day and each run generates 10 log files. JBOSS is up for a year, it will contains 18000 odd open file handle which is not acceptable.
> JBOSS version 3.2.3

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2910) minor try-finally
 changes to make
 sure that some streams and JDBC objects are always closed
Message-ID: <18321687.1159202941423.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2910?page=all ]

Dimitris Andreadis updated JBAS-2910:
-------------------------------------

    Component/s: CMP service
                 Web (Tomcat) service

> minor try-finally changes to make sure that some streams and JDBC objects are always closed
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2910
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2910
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, CMP service
>            Reporter: Westley Weimer
>            Priority: Minor
>   Original Estimate: 20 minutes
>  Remaining Estimate: 20 minutes
>
> Attached are minor candidate patches for jboss (against a CVS checkout of the sources on 2006 03 08) that ensure that resources are closed properly in some unlikely exceptional cases. These changse should not affect jboss functionality at all aside from ensuring that resources are closed in a few more cases. 
> This is hardly the most exciting sort of bugfix in the world, but jboss does seem to be concerned with leaks and being ironclad in these situations. The patches all have the general flavor of changing "open; work; close" to "try { open; work; } finally { close; }". It should take a knowledgeable dev at most a few minutes to eyeball them and accept or reject them. 
> I'm not sure how to attach the patch file, so I'm copying it here. My apologies if this is the wrong place for this sort of thing. 
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/CMPInMemoryPersistenceManager.java	2006-03-08 16:29:45.917109700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/CMPInMemoryPersistenceManager.java	2006-03-08 16:34:15.141058700 -0500
> @@ -355,11 +355,12 @@
>      */
>     public void loadEntity (EntityEnterpriseContext ctx)
>     {
> +      java.io.ObjectInputStream in = null;
>        try
>        {
>           // Read fields
>           
> -         java.io.ObjectInputStream in = new CMPObjectInputStream
> +         in = new CMPObjectInputStream
>              (new java.io.ByteArrayInputStream ((byte[])this.beans.get (ctx.getId ())));
>           
>           Object obj = ctx.getInstance ();
> @@ -370,12 +371,15 @@
>              f[i].set (obj, in.readObject ());
>           }
>           
> -         in.close ();
>        }
>        catch (Exception e)
>        {
>           throw new EJBException ("Load failed", e);
>        }
> +      finally
> +      {
> +        if (in != null) { try { in.close(); } catch (Exception e) { } }
> +      }
>     }
>     
>     /**
> --- jboss-20060308-orig/src/main/org/jboss/invocation/http/interfaces/Util.java	2006-03-08 16:29:47.899706700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/http/interfaces/Util.java	2006-03-08 17:32:40.259780600 -0500
> @@ -158,7 +158,9 @@
>        conn.setRequestProperty("ContentType", REQUEST_CONTENT_TYPE);
>        conn.setRequestMethod("POST");
>        OutputStream os = conn.getOutputStream();
> +      ObjectInputStream ois = null;
>        ObjectOutputStream oos = new ObjectOutputStream(os);
> +      try { 
>        try
>        {
>           oos.writeObject(mi);
> @@ -173,12 +175,14 @@
>  
>        // Get the response MarshalledValue object
>        InputStream is = conn.getInputStream();
> -      ObjectInputStream ois = new ObjectInputStream(is);
> +        ois = new ObjectInputStream(is);
>        MarshalledValue mv = (MarshalledValue) ois.readObject();
>        // A hack for jsse connection pooling (see patch ).
>        ois.read();
> -      ois.close();
> -      oos.close();
> +      } finally { 
> +        if (ois != null) { try { ois.close(); } catch (Exception e) { } } 
> +        if (oos != null) { try { oos.close(); } catch (Exception e) { } } 
> +      } 
>  
>        // If the encoded value is an exception throw it
>        Object value = mv.get();
> --- jboss-20060308-orig/src/main/org/jboss/invocation/MarshalledValue.java	2006-03-08 16:29:48.008983700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/MarshalledValue.java	2006-03-08 17:30:01.198298600 -0500
> @@ -89,9 +89,12 @@
>  
>        ByteArrayInputStream bais = new ByteArrayInputStream(serializedForm);
>        MarshalledValueInputStream mvis = new MarshalledValueInputStream(bais);
> +      try { 
>        Object retValue =  mvis.readObject();
> -      mvis.close();
>        return retValue;
> +      } finally { 
> +        mvis.close();
> +      } 
>     }
>  
>     public byte[] toByteArray()
> --- jboss-20060308-orig/src/main/org/jboss/invocation/pooled/interfaces/PooledMarshalledValue.java	2006-03-08 16:29:48.055816700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/pooled/interfaces/PooledMarshalledValue.java	2006-03-08 17:34:20.946787700 -0500
> @@ -90,9 +90,12 @@
>  
>        ByteArrayInputStream bais = new ByteArrayInputStream(serializedForm);
>        ObjectInputStream mvis = new OptimizedObjectInputStream(bais);
> +      try { 
>        Object retValue =  mvis.readObject();
> -      mvis.close();
>        return retValue;
> +      } finally { 
> +        try { mvis.close(); } catch (Exception e) { } 
> +      } 
>     }
>  
>     public byte[] toByteArray()
> --- jboss-20060308-orig/src/main/org/jboss/naming/HttpNamingContextFactory.java	2006-03-08 16:29:48.914421700 -0500
> +++ jboss-20060308/src/main/org/jboss/naming/HttpNamingContextFactory.java	2006-03-08 17:35:39.213414500 -0500
> @@ -132,8 +132,12 @@
>  
>        InputStream is = conn.getInputStream();
>        ObjectInputStream ois = new ObjectInputStream(is);
> -      MarshalledValue mv = (MarshalledValue) ois.readObject();
> -      ois.close();
> +      MarshalledValue mv = null;
> +      try { 
> +        mv = (MarshalledValue) ois.readObject();
> +      } finally { 
> +        try { ois.close(); } catch (Exception e) { } 
> +      } 
>  
>        Object obj = mv.get();
>        if( (obj instanceof Naming) == false )
> --- jboss-20060308-orig/src/main/org/jboss/web/AbstractWebContainer.java	2006-03-08 16:29:49.413973700 -0500
> +++ jboss-20060308/src/main/org/jboss/web/AbstractWebContainer.java	2006-03-08 17:37:40.449341300 -0500
> @@ -322,8 +322,11 @@
>                 throw new DeploymentException("Was unable to mkdir: "+expWarFile);
>              log.debug("Unpacking war to: "+expWarFile);
>              FileInputStream fis = new FileInputStream(warFile);
> +            try { 
>              JarUtils.unjar(fis, expWarFile);
> -            fis.close();
> +            } finally { 
> +              try { fis.close(); } catch (Exception e) { } 
> +            } 
>              log.debug("Replaced war with unpacked contents");
>              if (warFile.delete() == false)
>                 log.debug("Was unable to delete war file");
> @@ -416,6 +419,7 @@
>              
>              FileInputStream fis = new FileInputStream(warFile);
>              JarInputStream jin = new JarInputStream(fis);
> +            try { 
>              ZipEntry entry = jin.getNextEntry();
>              while (entry != null)
>              {
> @@ -426,8 +430,9 @@
>                 }
>                 entry = jin.getNextEntry();
>              }
> -            jin.close();
> -            
> +            } finally { 
> +              try { jin.close(); } catch (Exception e) { } 
> +            } 
>              URL[] urlArr = new URL[urlList.size()];
>              urlList.toArray(urlArr);
>              di.annotationsCl = new URLClassLoader(urlArr, di.ucl);
> @@ -706,6 +711,7 @@
>              // First check for a WEB-INF/web.xml and a WEB-INF/jboss-web.xml
>              InputStream warIS = warURL.openStream();
>              java.util.zip.ZipInputStream zipIS = new java.util.zip.ZipInputStream(warIS);
> +            try { 
>              java.util.zip.ZipEntry entry;
>              byte[] buffer = new byte[512];
>              int bytes;
> @@ -730,7 +736,9 @@
>                    jbossWebIS = new ByteArrayInputStream(baos.toByteArray());
>                 }
>              }
> -            zipIS.close();
> +            } finally { 
> +              try { zipIS.close(); } catch (Exception e) { } 
> +            } 
>           }
>  
>           XmlFileLoader xmlLoader = new XmlFileLoader();
> --- jboss-20060308-orig/src/main/org/jboss/web/WebServer.java	2006-03-08 16:29:49.445195700 -0500
> +++ jboss-20060308/src/main/org/jboss/web/WebServer.java	2006-03-08 17:38:28.403080100 -0500
> @@ -1,4 +1,4 @@
> -/*
> +/* } catch (Exception e) { } 
>  * JBoss, Home of Professional Open Source
>  * Copyright 2005, JBoss Inc., and individual contributors as indicated
>  * by the @authors tag. See the copyright.txt in the distribution for a
> @@ -521,6 +521,7 @@
>     protected byte[] getBytes(URL url) throws IOException
>     {
>        InputStream in = new BufferedInputStream(url.openStream());
> +      try { 
>        log.debug("Retrieving " + url);
>        ByteArrayOutputStream out = new ByteArrayOutputStream();
>        byte[] tmp = new byte[1024];
> @@ -529,8 +530,10 @@
>        {
>           out.write(tmp, 0, bytes);
>        }
> -      in.close();
>        return out.toByteArray();
> +      } finally { 
> +        try { in.close(); } catch (Exception e) { } 
> +      } 
>     }
>  
>     /**
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCDB2IdentityValLocalCreateCommand.java	2006-03-08 16:29:45.323891700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCDB2IdentityValLocalCreateCommand.java	2006-03-08 17:19:47.443491800 -0500
> @@ -44,8 +44,9 @@
>      protected int executeInsert(int paramIndex, PreparedStatement ps, EntityEnterpriseContext ctx ) throws SQLException {
>          int rows = ps.executeUpdate();
>          ResultSet results = null;
> +        Connection conn = null; 
>          try {
> -            Connection conn = ps.getConnection();
> +            conn = ps.getConnection();
>              results = conn.prepareStatement( SQL ).executeQuery();
>              if( !results.next() ) {
>                  throw new EJBException( "identity_val_local() returned an empty ResultSet" );
> @@ -58,6 +59,7 @@
>              throw new EJBException( "Error extracting identity_val_local()", e );
>          } finally {
>              JDBCUtil.safeClose( results );
> +            JDBCUtil.safeClose(con);
>          }
>          return rows;
>      }
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCPostgreSQLCreateCommand.java	2006-03-08 16:29:45.355113700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCPostgreSQLCreateCommand.java	2006-03-08 17:22:01.854042800 -0500
> @@ -74,11 +74,12 @@
>  
>        Statement s = null;
>        ResultSet rs = null;
> +      Connection c = null;
>        try {
>           if (trace) {
>              log.trace("Executing SQL :"+sequenceSQL);
>           }
> -         Connection c = ps.getConnection();
> +         c = ps.getConnection();
>           s = c.createStatement();
>           rs = s.executeQuery(sequenceSQL);
>           if (!rs.next()) {
> @@ -93,6 +94,7 @@
>        } finally {
>           JDBCUtil.safeClose(rs);
>           JDBCUtil.safeClose(s);
> +         JDBCUtil.safeClose(c);
>        }
>  
>        return rows;
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCSQLServerCreateCommand.java	2006-03-08 16:29:45.355113700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCSQLServerCreateCommand.java	2006-03-08 17:23:29.513540100 -0500
> @@ -61,10 +61,10 @@
>  
>     protected int executeInsert(int index, PreparedStatement ps, EntityEnterpriseContext ctx) throws SQLException
>     {
> -      ps.execute();
>        ResultSet rs = null;
>        try
>        {
> +         ps.execute();
>           int rows = ps.getUpdateCount();
>           if(rows != 1)
>           {
> @@ -95,6 +95,7 @@
>        finally
>        {
>           JDBCUtil.safeClose(rs);
> +         JDBCUtil.safeClose(ps);
>        }
>     }
>  }

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:52:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24139418.1159203121272.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3678?page=comments#action_12343977 ] 
            
Dimitris Andreadis commented on JBAS-3678:
------------------------------------------

Is this supposedly linked to JBAS-3651?

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Ryan Campbell
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 13:19:01 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Mon, 25 Sep 2006 13:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1318686.1159204741155.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3651?page=comments#action_12343980 ] 
            
Rajesh Rajasekaran commented on JBAS-3651:
------------------------------------------

The Solaris 10 box in the QA lab has been down. Still waiting on IT to get it back up and running.

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Ryan Campbell
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 13:31:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 13:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21934628.1159205461348.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3693?page=all ]

Weston Price resolved JBAS-3693.
--------------------------------

    Fix Version/s: JBossAS-4.0.5.CR1
                       (was: JBossAS-4.0.5.GA)
       Resolution: Done

Changed behavior for destroying XA resource on XAResource.end failure. Connections are no longer returned to the pool.

> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:10:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Mon, 25 Sep 2006 14:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3676) Upgrade
 jboss-common to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1196736.1159207801190.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3676?page=comments#action_12343983 ] 
            
Scott M Stark commented on JBAS-3676:
-------------------------------------

Depends on the 1.0.0.GA release of common:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&pid=12310265&fixfor=12310992

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Mon Sep 25 14:13:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Mon, 25 Sep 2006 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-11) Add a default
 client socket factory which supports setBindAddress
Message-ID: <7633012.1159207981178.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a default client socket factory which supports setBindAddress
-----------------------------------------------------------------

                 Key: JBCOMMON-11
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-11
             Project: JBoss Common
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: core
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: 1.0.0.GA


We need to have a default RMIClientSocketFactory impl that supports setBindAddress(String) for use in the invokers/naming service.


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:31:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 14:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-8) Port
 MarshalledValueIn(Out)putStream from aop
In-Reply-To: <14481718.1158259595983.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27165723.1159209061228.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-8?page=all ]

Brian Stansberry closed JBCOMMON-8.
-----------------------------------

    Fix Version/s: 1.0.0.GA
                       (was: 2.0.0.GA)
       Resolution: Done

> Port MarshalledValueIn(Out)putStream from aop
> ---------------------------------------------
>
>                 Key: JBCOMMON-8
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-8
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 1.0.0.GA
>
>
> A copy of AS/aop's MarshalledValueInputStream and MarshalledValueOutputStream should be added to common-core/org.jboss.util.stream.  These are prettyy straightforward extensions of the j2se ObjectStreams with only j2se dependencies.  Once a version of common with this in it is released, the other projects that use it can be converted.  Usages I'm aware of are:
> AS via its version in the server module
> AOP via its own version
> JBoss Cache via dependency on the AS's jboss-minimal.jar

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:34:01 2006
From: jira-events at jboss.com (Ryan Dewell (JIRA))
Date: Mon, 25 Sep 2006 14:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-161)
	Calendaring/scheduling
Message-ID: <20534147.1159209241801.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-161?page=comments#action_12343985 ] 
            
Ryan Dewell commented on JBSEAM-161:
------------------------------------

JMS messages, due to their asynchronous nature, may be a related problem as well.

> Calendaring/scheduling
> ----------------------
>
>                 Key: JBSEAM-161
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-161
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> We need calendared events to be processed in the scope of a Seam context. 
> We need to investigate what timer solutions make sense: jBPM, Quartz, EJB timers?

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:43:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 14:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-604) allow socket server
 invoker to accept third party requests
Message-ID: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>

allow socket server invoker to accept third party requests
----------------------------------------------------------

                 Key: JBREM-604
                 URL: http://jira.jboss.com/jira/browse/JBREM-604
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
             Fix For: 2.2.0.Beta1 (Bluto)


The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:46:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 14:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-604) allow socket
 server invoker to accept third party requests
In-Reply-To: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26660555.1159209961476.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-604?page=comments#action_12343988 ] 
            
Tom  Elrod commented on JBREM-604:
----------------------------------

The biggest issue with doing this is that is difficult to generate the remoting data needed on the server side, such as client session id and subsystem handler to route the request to.  

Have tried to do a best guess for this by getting the remote address for the calling socket and take the first supported subsystem defined withint the server invoker.  Obviously all the extra remoting features such as callbacks, leasing, etc. will not be available since thirdparty client will not be able to include the extra data needed for this on the server side.

> allow socket server invoker to accept third party requests
> ----------------------------------------------------------
>
>                 Key: JBREM-604
>                 URL: http://jira.jboss.com/jira/browse/JBREM-604
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:49:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 14:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-604) allow socket
 server invoker to accept third party requests
In-Reply-To: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24108219.1159210141047.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-604?page=comments#action_12343989 ] 
            
Tom  Elrod commented on JBREM-604:
----------------------------------

Test case: org.jboss.test.remoting.transport.socket.raw.RawTestCase

> allow socket server invoker to accept third party requests
> ----------------------------------------------------------
>
>                 Key: JBREM-604
>                 URL: http://jira.jboss.com/jira/browse/JBREM-604
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:55:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3695) Integrate JBC 2.0.0
	DR1 into HEAD
Message-ID: <8438968.1159210501062.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate JBC 2.0.0 DR1 into HEAD
---------------------------------

                 Key: JBAS-3695
                 URL: http://jira.jboss.com/jira/browse/JBAS-3695
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


The JBC team has cut a "JBossCache_2_0_DR1" release, which is really a pre-alpha snapshot for internal use.  Need to integrate this into HEAD so we can see the issues it raises.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 15:37:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Mon, 25 Sep 2006 15:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10116012.1159213021217.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3651?page=all ]

Ryan Campbell reassigned JBAS-3651:
-----------------------------------

    Assignee: Rajesh Rajasekaran  (was: Ryan Campbell)

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:43:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 16:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-553) Run AS (4.x
 and 5.x) integration tests with Messaging
Message-ID: <27353135.1159216981170.JavaMail.jira@cloud.prod.atl2.jboss.com>

Run AS (4.x and 5.x) integration tests with Messaging
-----------------------------------------------------

                 Key: JBMESSAGING-553
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-553
             Project: JBoss Messaging
          Issue Type: Task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz
            Priority: Critical
             Fix For: 1.2.0.Beta1


This is the container task for everthing required to run JBoss AS JMS integration tests with JBoss Messaging. The existing integration test framework should be modified in such a manner to allow interchangeably running the same JMS tests with JBossMQ and JBoss Messaging. None of the existing JBossMQ tests should be removed, they must be at most refactored so the JBossMQ-specific tests will be executed with JBossMQ only (as part of the JBossMQ functional testsuite) and generic JMS tests will be executed with both JBossMQ and JBoss Messaging.

More details in the sub-tasks.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:49:02 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 16:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3696) WebServices leaking
	redeployment
Message-ID: <32740588.1159217342062.JavaMail.jira@cloud.prod.atl2.jboss.com>

WebServices leaking redeployment
--------------------------------

                 Key: JBAS-3696
                 URL: http://jira.jboss.com/jira/browse/JBAS-3696
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
         Assigned To: Thomas Diesler
            Priority: Blocker
             Fix For: JBossAS-4.0.5.GA


org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata.

The current failures we are having on the TestSuite (OOME) are related to this task.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:55:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 16:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-554) Create an
 Admin abstraction
 that would allow running generic JMS tests regardless of provider
 implementation
Message-ID: <10709624.1159217701106.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create an Admin abstraction that would allow running generic JMS tests regardless of provider implementation
------------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-554
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-554
             Project: JBoss Messaging
          Issue Type: Sub-task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz
             Fix For: 1.2.0.Beta1


Since Messaging and JBossMQ use slightly different ways of deploying their administered objects (destinations and connection factories), we need to create an unified Admin interface that would allow to deploy these artifacts regardless of provider implementation, and then create plug-ins for Messaging and MQ. 

Initial work in this direction has been done by Adrian, see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:58:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 16:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3696) WebServices leaking
 redeployment
In-Reply-To: <32740588.1159217342062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15489905.1159217881526.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3696?page=comments#action_12343996 ] 
            
Clebert Suconic commented on JBAS-3696:
---------------------------------------

my suggestion for a fix would be to modify destory on ServiceEndpointDeployer:

   public void destroy(UnifiedDeploymentInfo udi) throws Throwable
   {
      log.debug("destroy: " + udi.url);

      UnifiedMetaData wsMetaData = getUnifiedMetaData(udi);
      if (wsMetaData != null)
      {
         // Destroy the service endpoints
         for (ServiceMetaData serviceMetaData : wsMetaData.getServices())
         {
            for (EndpointMetaData epMetaData : serviceMetaData.getEndpoints())
            {
               ObjectName sepID = ((ServerEndpointMetaData)epMetaData).getServiceEndpointID();
               epManager.destroyServiceEndpoint(sepID);
            }
         }
      }
      
      removeUnifiedMetaData(udi);
   }

   public void removeUnifiedMetaData(UnifiedDeploymentInfo udi)
   {
      metaDataMap.remove(udi.url.toExternalForm());
   }


> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3696
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata.
> The current failures we are having on the TestSuite (OOME) are related to this task.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:58:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 16:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-555) Separate
	generic JMS tests
Message-ID: <16889647.1159217881881.JavaMail.jira@cloud.prod.atl2.jboss.com>

Separate generic JMS tests
--------------------------

                 Key: JBMESSAGING-555
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-555
             Project: JBoss Messaging
          Issue Type: Sub-task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz
             Fix For: 1.2.0.Beta1


Separate the generic JMS tests by creating a copy of all JBossMQ tests and eliminating the JBossMQ-specific ones. The remaining tests will be refactored so they can be run with both Messaging and JBossMQ,

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:01:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-556) Isolate
 JBossMQ-specific test
Message-ID: <185690.1159218061132.JavaMail.jira@cloud.prod.atl2.jboss.com>

Isolate JBossMQ-specific test
-----------------------------

                 Key: JBMESSAGING-556
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-556
             Project: JBoss Messaging
          Issue Type: Sub-task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz


Isolate JbossMQ specific tests so they'll be run as the JBossMQ functional testsuite, and NOT as integration tests.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:04:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-385) Generalize
 jboss testsuite
 JMS tests to work with both Messaging and JBossMQ (where possible) and make
 sure they pass
Message-ID: <6055369.1159218241399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-385?page=all ]

Ovidiu Feodorov closed JBMESSAGING-385.
---------------------------------------

    Resolution: Duplicate Issue

Duplicate of http://jira.jboss.org/jira/browse/JBMESSAGING-555

> Generalize jboss testsuite JMS tests to work with both Messaging and JBossMQ (where possible) and make sure they pass
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-385
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-385
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: AS Integration
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.1
>
>
> More details on how to do that: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:04:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-386) Isolate
 JBossMQ-specific tests and make sure they pass
Message-ID: <22163649.1159218241649.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-386?page=all ]

Ovidiu Feodorov closed JBMESSAGING-386.
---------------------------------------

    Resolution: Duplicate Issue

Duplicate of http://jira.jboss.org/jira/browse/JBMESSAGING-556

> Isolate JBossMQ-specific tests and make sure they pass
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-386
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-386
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.1
>
>
> Move them inside the JBossMQ project as functional tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:07:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-185) Run objectweb
 JMS tests in top of JBoss Messaging
Message-ID: <30000533.1159218421250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-185?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-185:
-------------------------------------------

    Assignee: Richard Achmatowicz

> Run objectweb JMS tests in top of JBoss Messaging
> -------------------------------------------------
>
>                 Key: JBMESSAGING-185
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-185
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Richard Achmatowicz
>             Fix For: 1.2.1
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:16:03 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-553) Run AS (4.x
 and 5.x) integration tests with Messaging
In-Reply-To: <27353135.1159216981170.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14996750.1159218963463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-553?page=all ]

Ovidiu Feodorov updated JBMESSAGING-553:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3974027

> Run AS (4.x and 5.x) integration tests with Messaging
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-553
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-553
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>
> This is the container task for everthing required to run JBoss AS JMS integration tests with JBoss Messaging. The existing integration test framework should be modified in such a manner to allow interchangeably running the same JMS tests with JBossMQ and JBoss Messaging. None of the existing JBossMQ tests should be removed, they must be at most refactored so the JBossMQ-specific tests will be executed with JBossMQ only (as part of the JBossMQ functional testsuite) and generic JMS tests will be executed with both JBossMQ and JBoss Messaging.
> More details in the sub-tasks.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:22:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3696) WebServices leaking
	redeployment
In-Reply-To: <32740588.1159217342062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11532640.1159219321314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3696?page=all ]

Clebert Suconic updated JBAS-3696:
----------------------------------

    Description: 
org.jboss.ws.metadata.UnifiedMetaData has two strong references * to ClassLoader, and Undeployers are not releasing references to the metadata.
The one is showing up on my reports is field classLoader on UnifiedMetaData

The current failures we are having on the TestSuite (OOME) are related to this task.


*= strong reference is just a regular reference (non Weak, non Soft)

  was:
org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata.

The current failures we are having on the TestSuite (OOME) are related to this task.


> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3696
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> org.jboss.ws.metadata.UnifiedMetaData has two strong references * to ClassLoader, and Undeployers are not releasing references to the metadata.
> The one is showing up on my reports is field classLoader on UnifiedMetaData
> The current failures we are having on the TestSuite (OOME) are related to this task.
> *= strong reference is just a regular reference (non Weak, non Soft)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:28:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:28:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <21624541.1159219723903.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Description: 
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

  was:
It's possible to use JVMTIInterface from JBossProfiler to validate if an undeployment is releasing classes, by doing assertions on certain queries made to JVMTI.

Example:


		jvmtiInterface.forceGC();
		Object[] classes = jvmtiInterface.getAllObjects(Class.class);

                Class classFound;		
		for (int i=0;i<classes.length;i++)
		{
			Class theClass = (Class)classes[i];
			if (theClass.getName().equals("org.jboss.test.SomeEJB"))
			{
				classFound=theClass;
			}
		}

                if (classFound)
                {
                           fail("Undeployment couldn't clean org.jboss.test.SomeEJB");
                }


Of course that feature will be optional, and used in certain testcases only. This way we will assure that memory leaks are not introduced on tested places.

     Complexity: High

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:40:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <25379337.1159220401223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Description: 
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:

                jvmtiInterface.forceReleaseOfGC();
                Class[] classes = jvmtiInterface.getLoadedClasses();



  was:
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).


> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:46:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <21733650.1159220761570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Comment: was deleted

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:46:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <2517070.1159220761723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Comment: was deleted

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:46:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <5609733.1159220761846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Description: 
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:

                jvmtiInterface.forceReleaseOfGC();
                Class[] classes = jvmtiInterface.getLoadedClasses();



  was:
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:

                jvmtiInterface.forceReleaseOfGC();
                Class[] classes = jvmtiInterface.getLoadedClasses();




> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:49:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <25116454.1159220941162.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Assignee: Rajesh Rajasekaran  (was: Clebert Suconic)

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:55:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Mon, 25 Sep 2006 17:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-11) Add a default
 client socket factory which supports setBindAddress
In-Reply-To: <7633012.1159207981178.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22564337.1159221301267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-11?page=all ]

Scott M Stark closed JBCOMMON-11.
---------------------------------

    Fix Version/s: 2.0.1.GA
       Resolution: Done

org.jboss.net.sockets.DefaultClientSocketFactory has been added to the common-core.

> Add a default client socket factory which supports setBindAddress
> -----------------------------------------------------------------
>
>                 Key: JBCOMMON-11
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-11
>             Project: JBoss Common
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> We need to have a default RMIClientSocketFactory impl that supports setBindAddress(String) for use in the invokers/naming service.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:55:01 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 25 Sep 2006 17:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1047) Design ldap
 implementation for identity modules
In-Reply-To: <3389991.1158568372948.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25543997.1159221301580.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1047?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1047.
-------------------------------------------

    Resolution: Done

> Design ldap implementation for identity modules
> -----------------------------------------------
>
>                 Key: JBPORTAL-1047
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1047
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 days, 1 hour
>
> - Identity modules must handle both user/role retreival and creation 
> - User and roles can be mapped in ldap directory tree in several different ways.
> - There should be some flexible implementation desinged to handle different user/roles relations mapping strategies. (roles, group, both static and dynamic)
> - This should also be opened for additional specific features for main LDAP implementations (RH, Sun, MSAD...)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:19:02 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 18:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-465) Refactor state
 transfer code out of TreeCache
Message-ID: <33048198.1159222742222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-465?page=all ]

Brian Stansberry closed JBCACHE-465.
------------------------------------

    Resolution: Done

> Refactor state transfer code out of TreeCache
> ---------------------------------------------
>
>                 Key: JBCACHE-465
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-465
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.0.0
>
>
> The TreeCache class now has a ton of code related to state transfer.  Need to look into refactoring that out into a separate class or classes.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:22:02 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 18:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25716879.1159222922038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3659?page=all ]

Brian Stansberry updated JBAS-3659:
-----------------------------------

    Description: 
The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.

We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB receive buffers  and 640K send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the send buffers to 640K and the receives to 2MB.

  was:
The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.

We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.


> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB receive buffers  and 640K send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the send buffers to 640K and the receives to 2MB.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:25:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 18:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16033403.1159223101043.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3659?page=all ]

Brian Stansberry closed JBAS-3659.
----------------------------------

    Resolution: Done

> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB receive buffers  and 640K send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the send buffers to 640K and the receives to 2MB.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:02 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-59) get original BPEL
 document after deployment
Message-ID: <6743049.1159224362383.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-59?page=all ]

Alejandro Guizar updated BPEL-59:
---------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> get original BPEL document after deployment
> -------------------------------------------
>
>                 Key: BPEL-59
>                 URL: http://jira.jboss.com/jira/browse/BPEL-59
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 3
>            Reporter: Dmitry
>         Assigned To: Alejandro Guizar
>            Priority: Minor
>             Fix For: jBPM BPEL 1.1
>
>
> i'm developing a BAM system(http://sourceforge.net/projects/jbam). and i need on my presentation part of the system show the user on what step of the execution of the process are we currently on. i'm intercepting JBPM system ivents via JBossAOP framework, and as a reason of it have no problem to know on which step of process instance execution are we currently on and what is my input data, but i can't meanwhile to find way to get process flow definition. according to my design i would like to get on each processinstance start a process xml model so i could transform it to SVG and show to end user on portal(the representation on my system). this is needed becouse process might have different versions and i'd like to show to user the updated one or busuness analyst might what to know how did the process flow looked two month ago, and this information i can give him from my database if i have xml definition stored inside it.
> Regards,
> Dmitry.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:02 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-10) compensation handling
Message-ID: <5826820.1159224362789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-10?page=all ]

Alejandro Guizar updated BPEL-10:
---------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> compensation handling
> ---------------------
>
>                 Key: BPEL-10
>                 URL: http://jira.jboss.com/jira/browse/BPEL-10
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Juan Cantu
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> -Implement the state transitions for scope instances when compensate / compensated signals are received 
> -support implicit compensation

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:02 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-193) template for new
	projects
Message-ID: <5287690.1159224362909.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-193?page=all ]

Alejandro Guizar updated BPEL-193:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> template for new projects
> -------------------------
>
>                 Key: BPEL-193
>                 URL: http://jira.jboss.com/jira/browse/BPEL-193
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Burr Sutter wrote:
> "I was only hoping for an easy way to build, modify and redeploy HelloWorld or ATM with the least amount of effort.  Something like
> 1. Edit BPEL file
> 2. Deploy
> 3. In the browser view the WSDL
> Having Ant tasks that make it this easy and a template project and build script for getting started would be great for the first release of our BPEL engine."

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-200) Redeployment of a
 changed PAR (with modified .bpel) requires App Server Restart
In-Reply-To: <16886597.1153430291450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22491588.1159224363534.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-200?page=all ]

Alejandro Guizar updated BPEL-200:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> Redeployment of a changed PAR (with modified .bpel) requires App Server Restart
> -------------------------------------------------------------------------------
>
>                 Key: BPEL-200
>                 URL: http://jira.jboss.com/jira/browse/BPEL-200
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 1
>         Environment: JBoss 4.0.4.GA with EJB3 using beta JEMS installer 
>            Reporter: Burr Sutter
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Simply modifying the .bpel script, running pack-definition and deploy-definition do not reload/restart the process (even though all process instances have terminated).  The only thing I've found that refreshes the BPEL engine properly is to restart the App Server.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-168) soap header processing
Message-ID: <15539127.1159224363696.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-168?page=all ]

Alejandro Guizar updated BPEL-168:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> soap header processing
> ----------------------
>
>                 Key: BPEL-168
>                 URL: http://jira.jboss.com/jira/browse/BPEL-168
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Extract the WSDL message parts carried in SOAP headers and add them to incoming requests.
> Make sure this mechanism properly makes WS-Addressing headers available to the process.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-201) Release 1.1 beta 3
In-Reply-To: <4511003.1153758791655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31354993.1159224363822.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-201?page=all ]

Alejandro Guizar updated BPEL-201:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> Release 1.1 beta 3
> ------------------
>
>                 Key: BPEL-201
>                 URL: http://jira.jboss.com/jira/browse/BPEL-201
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> The focus of this release is on fault handlers and compensation.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-151) export the reference
 of the published endpoint
Message-ID: <30788981.1159224363974.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-151?page=all ]

Alejandro Guizar updated BPEL-151:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> export the reference of the published endpoint
> ----------------------------------------------
>
>                 Key: BPEL-151
>                 URL: http://jira.jboss.com/jira/browse/BPEL-151
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1
>
>
> Provide the endpoint reference of the process with respect to partner links. Implement its use as the source of assignment, as described in section 9.4 of the spec.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:04 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-144) publish
	document/literal endpoints
Message-ID: <17323294.1159224364119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-144?page=all ]

Alejandro Guizar updated BPEL-144:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> publish document/literal endpoints
> ----------------------------------
>
>                 Key: BPEL-144
>                 URL: http://jira.jboss.com/jira/browse/BPEL-144
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>         Environment: jaxrpc, saaj, w3c dom
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> jBPM BPEL currently generates service WSDL documents and processes SOAP request/response messages only for RPC/literal web services. Enhancing the service generation tool and the JAX-RPC handler to cover the document style is crucial for interoperability, particulary with .NET.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:04 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-9) fault and termination
	handling
Message-ID: <19191364.1159224364371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-9?page=all ]

Alejandro Guizar updated BPEL-9:
--------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> fault and termination handling
> ------------------------------
>
>                 Key: BPEL-9
>                 URL: http://jira.jboss.com/jira/browse/BPEL-9
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Juan Cantu
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> -Implement the state transitions for scope instances when cancel or faulted signals are received 
> -Provide the fault catching logic

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:04 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-85) Docu on the purpose of
	BPEL
Message-ID: <5251899.1159224364585.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-85?page=all ]

Alejandro Guizar updated BPEL-85:
---------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 2)

> Docu on the purpose of BPEL
> ---------------------------
>
>                 Key: BPEL-85
>                 URL: http://jira.jboss.com/jira/browse/BPEL-85
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Thomas Diesler
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Please expand the user documentation to a section about the purpose of BPEL. It should show a not so trivial use case that illustrates (with pictures) why I should care about BPEL

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 19:22:01 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Mon, 25 Sep 2006 19:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-605) Inform a server side
 listener that a callback has been delivered.
Message-ID: <32739313.1159226521194.JavaMail.jira@cloud.prod.atl2.jboss.com>

Inform a server side listener that a callback has been delivered.
-----------------------------------------------------------------

                 Key: JBREM-605
                 URL: http://jira.jboss.com/jira/browse/JBREM-605
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.Beta1 (Bluto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.0.Beta1 (Bluto)


JBossMessaging has a need to know that a Callback has been pulled to the client side and has been processed. 

See JBMESSAGING-207 for some discussion.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 19:58:01 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 19:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-212) Modularize package
 org.jbpm.bpel.def
Message-ID: <7572.1159228681195.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modularize package org.jbpm.bpel.def
------------------------------------

                 Key: BPEL-212
                 URL: http://jira.jboss.com/jira/browse/BPEL-212
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: jBPM BPEL 1.1 beta 2
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1


The package org.jbpm.bpel.def concentrates all activity definitions and has become monolithic. The proposal is breaking it as follows:

org.jbpm.bpel.graph.def: Core concepts, including BpelDefinition, Activity, CompositeActivity and LinkDefinition.
org.jbpm.bpel.graph.basic: Basic activities
org.jbpm.bpel.graph.struct: Structured activities
org.jbpm.bpel.graph.scope: Scope activity plus fault, compensation, event and termination handlers

For consistency, org.jbpm.bpel.exe becomes org.jbpm.bpel.graph.exe. Because the number of execution objects is small, there is no need to break this package.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:31:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-604) allow socket server
 invoker to accept third party requests
In-Reply-To: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13933991.1159237861119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-604?page=all ]

Tom  Elrod resolved JBREM-604.
------------------------------

    Resolution: Done

> allow socket server invoker to accept third party requests
> ----------------------------------------------------------
>
>                 Key: JBREM-604
>                 URL: http://jira.jboss.com/jira/browse/JBREM-604
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:31:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-548) Support one way
 invocations with no response
In-Reply-To: <22298973.1153332911695.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12288259.1159237861306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-548?page=all ]

Tom  Elrod resolved JBREM-548.
------------------------------

    Resolution: Done

> Support one way invocations with no response
> --------------------------------------------
>
>                 Key: JBREM-548
>                 URL: http://jira.jboss.com/jira/browse/JBREM-548
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Tim Fox
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The current remoting implementation of a client side one way invocations just performs a standard two way invocation on a different thread and returns without waiting for the result.
> JBoss Messaging would like to have a one way invocation which just performs a write to the underlying stream (e.g. socket outpustream) and continues without waiting for the result. This would result in less blocking and better performance since redundant writes for the invocation response would be ommitted,

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:34:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 22:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-548) Support one way
 invocations with no response
In-Reply-To: <22298973.1153332911695.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2272682.1159238041275.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-548?page=comments#action_12344022 ] 
            
Tom  Elrod commented on JBREM-548:
----------------------------------

For the socket invoker and making oneway call, the client will only write data to wire and return without waiting to read data off the wire and the server will only read data from the wire and will throw away handler response and will not write it to the wire.

> Support one way invocations with no response
> --------------------------------------------
>
>                 Key: JBREM-548
>                 URL: http://jira.jboss.com/jira/browse/JBREM-548
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Tim Fox
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The current remoting implementation of a client side one way invocations just performs a standard two way invocation on a different thread and returns without waiting for the result.
> JBoss Messaging would like to have a one way invocation which just performs a write to the underlying stream (e.g. socket outpustream) and continues without waiting for the result. This would result in less blocking and better performance since redundant writes for the invocation response would be ommitted,

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:58:01 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Mon, 25 Sep 2006 22:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-149) Refactor Object
 Store as per design goals for G.A release
Message-ID: <27758571.1159239481343.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor Object Store as per design goals for G.A release
---------------------------------------------------------

                 Key: JBESB-149
                 URL: http://jira.jboss.com/jira/browse/JBESB-149
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Daniel Brum
         Assigned To: Daniel Brum
             Fix For: 4.0


Change Rosetta Object Store implementation to support Re-Architecture Message changes.
- remove EJB dependency, standalone service
- change DB pool logic (Apache project?)
- support persisting and lookup of Message
- pluggable persistence engine, i.e: database or file, or other.  For G.A only database to be supported


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 23:01:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Mon, 25 Sep 2006 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-785) InvocationContext
 and suspended transactions
Message-ID: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>

InvocationContext and suspended transactions
--------------------------------------------

                 Key: JBCACHE-785
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani


The attached test case demonstrates that if you:

 A) Make calls to the tree cache
 B) suspend the current transaction
 C) Make more calls to the tree cache

The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.

It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 23:04:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Mon, 25 Sep 2006 23:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-785) InvocationContext
 and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16214092.1159239841297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=all ]

Owen Taylor updated JBCACHE-785:
--------------------------------

    Attachment: SuspendTxTest.java

> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>         Attachments: SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:07:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 00:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3697) Port BR test of
 ClusteredSSO to HEAD
Message-ID: <33382617.1159243621195.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port BR test of ClusteredSSO to HEAD
------------------------------------

                 Key: JBAS-3697
                 URL: http://jira.jboss.com/jira/browse/JBAS-3697
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


Port to HEAD once it stabilizes and the new deployer structure is clear.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:07:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 00:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3487) Create test of
 ClusteredSingleSignOn with BR enabled
In-Reply-To: <31521015.1154989995283.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3746659.1159243621316.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3487?page=all ]

Brian Stansberry closed JBAS-3487.
----------------------------------

    Resolution: Done

Done in Branch_4_0.

> Create test of ClusteredSingleSignOn with BR enabled
> ----------------------------------------------------
>
>                 Key: JBAS-3487
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3487
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to toggle the buddyReplicationEnabled attribute, restart and re-run.  I've already tested it works manually; need to add to suite to ensure there are no regressions.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:10:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 00:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-785)
 InvocationContext and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30138664.1159243801365.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=comments#action_12344024 ] 
            
Owen Taylor commented on JBCACHE-785:
-------------------------------------

I probably should also mention the context: this problem occurs with the text.hibernate.cache.TreeCache.put() which suspends the current transaction when caching data into the cache after a cache miss. I believe (but have not verified experimentally) that it will also occur with the suspend that is done internally inside the tree cache when Option.setFailSilently() has been called.


> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>         Attachments: SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:34:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 00:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-785) InvocationContext
 and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1569877.1159245241304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=all ]

Owen Taylor updated JBCACHE-785:
--------------------------------

    Attachment: hibernate-suspend-workaround.patch

For reference, here's a workaround patch for Hibernate

> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>         Attachments: hibernate-suspend-workaround.patch, SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 01:40:01 2006
From: jira-events at jboss.com (uphaar kotru (JIRA))
Date: Tue, 26 Sep 2006 01:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3698) JNDI Lookup returns
	null
Message-ID: <8105736.1159249201465.JavaMail.jira@cloud.prod.atl2.jboss.com>

JNDI Lookup returns null
------------------------

                 Key: JBAS-3698
                 URL: http://jira.jboss.com/jira/browse/JBAS-3698
             Project: JBoss Application Server
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.3 SP1
         Environment: WIndows XP 2002 SP2
            Reporter: uphaar kotru
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.2 Final


I am having issue with jndi lookup for my datasource in 4.0.3 SP1. The jndi is getting bound properly but while I try to lookup, it returns null. 
When I use exactly same WAR file and Oracle-DS.xml on 4.0.2, it works fine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 03:25:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 03:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3698) JNDI Lookup returns
	null
Message-ID: <10134967.1159255501672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3698?page=all ]

Dimitris Andreadis closed JBAS-3698.
------------------------------------


Please, use the forums to ask for help, this is not a bug report.

> JNDI Lookup returns null
> ------------------------
>
>                 Key: JBAS-3698
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3698
>             Project: JBoss Application Server
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>         Environment: WIndows XP 2002 SP2
>            Reporter: uphaar kotru
>         Assigned To: Scott M Stark
>             Fix For: No Release
>
>
> I am having issue with jndi lookup for my datasource in 4.0.3 SP1. The jndi is getting bound properly but while I try to lookup, it returns null. 
> When I use exactly same WAR file and Oracle-DS.xml on 4.0.2, it works fine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 03:25:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 03:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-3698) JNDI Lookup returns
	null
Message-ID: <14063054.1159255501863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3698?page=all ]

Dimitris Andreadis deleted JBAS-3698:
-------------------------------------


> JNDI Lookup returns null
> ------------------------
>
>                 Key: JBAS-3698
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3698
>             Project: JBoss Application Server
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>         Environment: WIndows XP 2002 SP2
>            Reporter: uphaar kotru
>         Assigned To: Scott M Stark
>
> I am having issue with jndi lookup for my datasource in 4.0.3 SP1. The jndi is getting bound properly but while I try to lookup, it returns null. 
> When I use exactly same WAR file and Oracle-DS.xml on 4.0.2, it works fine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:16:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3699) Fix testsuite OOMEs
Message-ID: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix testsuite OOMEs
-------------------

                 Key: JBAS-3699
                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:16:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25149248.1159258561843.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3699?page=comments#action_12344027 ] 
            
Dimitris Andreadis commented on JBAS-3699:
------------------------------------------

It seems there is a memory leak during webservices redeployment (JBWS-1228) so I'm going to exclude the webservices tests for now, to proceed with the rest of the testsuite.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:22:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 04:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24093870.1159258921571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

        Summary: Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages  (was: FileCacheLoader can return null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn))
    Description: 
FileCacheLoader can return a null value for get(fqn) if the node does not exist.

 /**
    * Returns all keys and values from the persistent store, given a fully qualified name.
    *
    * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
    * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
    * implementations should be checked for compliance with the behaviour expected.
    *
    * @param name
    * @return Map<Object,Object> keys and values for the given node. Returns
    * null if the node is not found.  If the node is found but has no
    * attributes, this method returns an empty Map.
    * @throws Exception
 */

If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
following misleading warning message is logged:

10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.

This occurrs even though the FileCacheLoader is actually doing the job accordingly.

  was:
FileCacheLoader can return a null value for get(fqn) which goes against the JavaDoc 
requirements for that method:

 /**
    * Returns all keys and values from the persistent store, given a fully qualified name.
    *
    * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
    * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
    * implementations should be checked for compliance with the behaviour expected.
    *
    * @param name
    * @return Map<Object,Object> keys and values for the given node. Returns
    * null if the node is not found.  If the node is found but has no
    * attributes, this method returns an empty Map.
    * @throws Exception
 */

If a get(fqn) operation occurrs before a put and the node (directory) does not exist, FCL returns 
null when it should return an empty Map.

If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
following misleading warning message is logged:

10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.


Update the case comment and title due to misunderstanding of the javadoc.
FileCacheLoader fullfills the javadoc, but in the special occasion of having a custom
cache loader that delegates on a org.jboss.cache CacheLoader, this WARN messages
would be log thinking that the newly create custom cache loader is breaking the contract.

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:46:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 04:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3484) non portable JDK
 dependant clasess (sun.**)
In-Reply-To: <23337773.1154968092604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20836870.1159260361700.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3484?page=all ]

Dimitris Andreadis closed JBAS-3484.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

I looked again at all cases and there is no remaining reference to sun classes.

> non portable JDK dependant clasess (sun.**)
> -------------------------------------------
>
>                 Key: JBAS-3484
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3484
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Security
>    Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.0.4.GA
>            Reporter: Andrew Oliver
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> We should not be using sun.** classes in tests or in code.   they are naughty and break working on non Sun JDKs.
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -i "sun.misc.BASE64Encoder" '{}' ';'
>       sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc.BASE64Encoder" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:   /** Compare Util.encodeBase64 against the sun misc class
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * Eliminates dependency on sun.misc.Base64Encoding,
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * (it's an access exception to load sun.misc.* classes
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.io" '{}' ';'
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:         sun.io.CharToByteUTF8 conv = new sun.io.CharToByteUTF8();
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:      } catch ( sun.io.MalformedInputException e ) {
> [andy at localhost jboss-4.0.x]$
> Moreover the 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:07:01 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Tue, 26 Sep 2006 05:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.0.4.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8551371.1159261621256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Thomas Diesler updated JBAS-3626:
---------------------------------

    Summary: Upgrade jbossws to 1.0.4.GA  (was: Upgrade jbossws to 1.1.0.GA)

> Upgrade jbossws to 1.0.4.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:22:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 05:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6945609.1159262521261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

    Affects Version/s: 2.0.0

Added 2.0

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:26:01 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 26 Sep 2006 05:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-785) InvocationContext
 and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29439343.1159262761286.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=all ]

Manik Surtani updated JBCACHE-785:
----------------------------------

    Fix Version/s: 1.4.0.SP2
                   2.0.0

> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0, 1.4.0.SP2
>
>         Attachments: hibernate-suspend-workaround.patch, SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:55:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27216176.1159264501127.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

    Affects Version/s:     (was: 2.0.0)

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:16:01 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Tue, 26 Sep 2006 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3700) Declared SQL Finder
 does not work with cmp2.x jdbc2 pm
Message-ID: <16043677.1159265761680.JavaMail.jira@cloud.prod.atl2.jboss.com>

Declared SQL Finder does not work with cmp2.x jdbc2 pm
------------------------------------------------------

                 Key: JBAS-3700
                 URL: http://jira.jboss.com/jira/browse/JBAS-3700
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: anajavi
         Assigned To: Alexey Loubyansky


When using declared sql where clause in finder, the generated sql does not contain all the fields of the entity. The cmp2.x jdbc2 pm requires the query to return all the fields. This causes an exception when the finder is invoked.

This is caused by DeclaredSQLQueryCommand.java and method buildSQL:
      if(metadata.getFieldName() == null)
      {
         // we are selecting a full entity
         table = this.entity.getQualifiedTableName();

         // get a list of all fields to be loaded
         // put pk fields in front
         String tableAlias = getTableAlias(alias, from, this.entity.getTableName());
         selectList = SQLUtil.getColumnNamesClause(this.entity.getPrimaryKeyFields(),
            tableAlias,
            new StringBuffer(35)).toString();
      }


Quick fix is to change this.entity.getPrimaryKeyFields() to this.entity.getTableFields().

The configurations:

ejb-jar.xml:
         <query>
            <query-method>
               <method-name>findByNimi</method-name>
               <method-params>
                  <method-param>java.lang.String</method-param>
               </method-params>
            </query-method>
            <ejb-ql><![CDATA[SELECT OBJECT(o) FROM Yritys AS o WHERE o.nimi=?1]]></ejb-ql>
         </query>


jbosscmp-jdbc.xml:
         <query>
                        <description/>
            <query-method>
               <method-name>findByNimi</method-name>
               <method-params>
                  <method-param>java.lang.String</method-param>
               </method-params>
            </query-method>

            <declared-sql>
                <where><![CDATA[upper(nimi) like upper({0})]]></where>
            </declared-sql>
         </query>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:19:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1102468.1159265941081.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno updated JBCACHE-776:
-------------------------------------

    Fix Version/s: 1.4.0.SP2

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:28:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18835344.1159266481409.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno resolved JBCACHE-776.
--------------------------------------

    Resolution: Done

EvictionPolicyProvider deprecated message downgraded from WARN to DEBUG.

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:43:02 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Tue, 26 Sep 2006 06:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3350) NPE on web service
	deployment
Message-ID: <20018574.1159267382259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3350?page=all ]

Thomas Diesler reassigned JBAS-3350:
------------------------------------

    Assignee: Remy Maucherat

Remy, could you please have a look.

> NPE on web service deployment
> -----------------------------
>
>                 Key: JBAS-3350
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3350
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Remy Maucherat
>
> tdiesler at TDDELL /cygdrive/d/svn/jbossws/trunk/src/test
> $ ant -Dtest=org.jboss.test.ws.wsse.WebClientTestCase one-test
> 2006-06-29 11:02:35,953 ERROR [org.apache.catalina.startup.ContextConfig] Parse error in application web.xml file at jndi:/localhost/jbossws-wsse-rpc/WEB-INF/web.xml
> java.lang.NullPointerException
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2725)
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2751)
> 	at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060)
> 	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
> <web-app version='2.4' xmlns='http://java.sun.com/xml/ns/j2ee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd'>
>  <servlet>
>   <servlet-name>Hello</servlet-name>
>   <servlet-class>org.jboss.ws.integration.jboss.JBossServiceEndpointServlet</servlet-class>
>   <init-param>
>    <param-name>ServiceEndpointImpl</param-name>
>    <param-value>org.jboss.test.ws.wsse.HelloJavaBean</param-value>
>   </init-param>
>  </servlet>
>  <servlet>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <servlet-class>org.jboss.test.ws.wsse.RpcTestClientServlet</servlet-class>
>  </servlet>
>  <servlet-mapping>
>   <servlet-name>Hello</servlet-name>
>   <url-pattern>/Hello</url-pattern>
>  </servlet-mapping>
>  <servlet-mapping>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <url-pattern>/RpcTestClientServlet</url-pattern>
>  </servlet-mapping>
>  <service-ref>
>   <service-ref-name>service/HelloService</service-ref-name>
>   <service-interface>javax.xml.rpc.Service</service-interface>
>   <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
>   <jaxrpc-mapping-file>WEB-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
>   <port-component-ref>
>    <service-endpoint-interface>org.jboss.test.ws.wsse.Hello</service-endpoint-interface>
>   </port-component-ref>
>  </service-ref>
> </web-app>

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:28:02 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7287838.1159266482179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

    Fix Version/s: 1.4.0.SP2

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:28:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-777) Creating a
 custom cache
 loader which delegates to a standard cache loader, can generate misleading
 WARN messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15256736.1159266481994.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=comments#action_12344032 ] 
            
Galder Zamarreno commented on JBCACHE-777:
------------------------------------------

Removed 2.0 (head)

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:14:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 26 Sep 2006 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-755) streamline designer
	build
Message-ID: <1177345.1159269241260.JavaMail.jira@cloud.prod.atl2.jboss.com>

streamline designer build
-------------------------

                 Key: JBPM-755
                 URL: http://jira.jboss.com/jira/browse/JBPM-755
             Project: JBoss jBPM
          Issue Type: Task
          Components: Graphical Process Designer
            Reporter: Tom Baeyens
         Assigned To: Koen Aers
            Priority: Critical


1) Remove usage of jbpm.version.  
* The docs should not be included directly in the designer plugin.  Instead, in the help docs, a reference should be published to the docs of the configured runtimes.
* The jbpm version constant should be removed cause it's not used any more.

When fixing this, make sure to do a search for jbpm.version.  

2) Rename jbpm.gpd.version to module.version so that it is in sync with all other jbpm subprojects.  Make sure that the used definition is located in the version.properties file and that the property definition in the build.xml is removed.

3) Remove all CVS checkout stuff.  Have the build fail in case one of the submodules is not present.   No cvs checkout should be done in case a module is missing.  Later we'll define a cvs checkout script in the overall build.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:19:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-133) Correct handling of
 one phase commit heuristics
Message-ID: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>

Correct handling of one phase commit heuristics
-----------------------------------------------

                 Key: JBTM-133
                 URL: http://jira.jboss.com/jira/browse/JBTM-133
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.

The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-133) Correct handling of
 one phase commit heuristics
In-Reply-To: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11063022.1159270081382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-133?page=comments#action_12344035 ] 
            
Kevin Conner commented on JBTM-133:
-----------------------------------

Fixed in revision 6431.


> Correct handling of one phase commit heuristics
> -----------------------------------------------
>
>                 Key: JBTM-133
>                 URL: http://jira.jboss.com/jira/browse/JBTM-133
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.
> The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-102) Need for a migration
	document
In-Reply-To: <1741379.1154429291404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6091621.1159270081727.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-102?page=all ]

Mark Little updated JBESB-102:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Need for a migration document
> -----------------------------
>
>                 Key: JBESB-102
>                 URL: http://jira.jboss.com/jira/browse/JBESB-102
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.1
>
>
> Because there may be some significant differences between the beta and GA releases of JBossESB 4.0, we need a migration document that summarises those changes.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:26:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 07:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-59) Add in generic bus
	abstraction
Message-ID: <22553256.1159269961911.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-59?page=all ]

Mark Little updated JBESB-59:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Add in generic bus abstraction
> ------------------------------
>
>                 Key: JBESB-59
>                 URL: http://jira.jboss.com/jira/browse/JBESB-59
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.1
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> Prior to Rosetta, we had the notion of a generic bus with client/service plugins, dispatchers and a message format. All of this needs to be added back to the new codebase.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:26:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 07:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-135) Integration with
 Microcontainer (IoC abstraction)
In-Reply-To: <11365425.1157552071692.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13944806.1159269961774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-135?page=all ]

Mark Little updated JBESB-135:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Integration with Microcontainer (IoC abstraction)
> -------------------------------------------------
>
>                 Key: JBESB-135
>                 URL: http://jira.jboss.com/jira/browse/JBESB-135
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Critical
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-133) Correct handling of
 one phase commit heuristics
In-Reply-To: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25855701.1159270081496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-133?page=all ]

Kevin Conner resolved JBTM-133.
-------------------------------

    Resolution: Done

> Correct handling of one phase commit heuristics
> -----------------------------------------------
>
>                 Key: JBTM-133
>                 URL: http://jira.jboss.com/jira/browse/JBTM-133
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.
> The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-133) Correct handling of
 one phase commit heuristics
In-Reply-To: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1539270.1159270081835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-133?page=all ]

Kevin Conner closed JBTM-133.
-----------------------------


> Correct handling of one phase commit heuristics
> -----------------------------------------------
>
>                 Key: JBTM-133
>                 URL: http://jira.jboss.com/jira/browse/JBTM-133
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.
> The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 08:25:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Tue, 26 Sep 2006 08:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16269866.1159273501164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-79?page=all ]

Alexey Loubyansky closed JBXB-79.
---------------------------------

    Resolution: Done

This issue was fixed as part of the JBXB-76. A test was added to org.jboss.test.xml.ArrayWrapperUnitTestCase.

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 08:40:01 2006
From: jira-events at jboss.com (Dave Caruana (JIRA))
Date: Tue, 26 Sep 2006 08:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-756) log.debug calls are
	unprotected
Message-ID: <5660338.1159274401349.JavaMail.jira@cloud.prod.atl2.jboss.com>

log.debug calls are unprotected
-------------------------------

                 Key: JBPM-756
                 URL: http://jira.jboss.com/jira/browse/JBPM-756
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: Window XP, Java 5
            Reporter: Dave Caruana
         Assigned To: Tom Baeyens


Within org.jbpm.context.exe.VariableContainer there are calls to log.debug.  In particular:

line 156:      log.debug("create variable '"+name+"' in '"+this+"' with value '"+value+"'");

line 160:      log.debug("update variable '"+name+"' in '"+this+"' to value '"+value+"'");

However, they are unprotected i.e. the method is called even if debug logging is not switched on.  This is not too much of a problem if the variable value is of a primitive type, but sometimes, values can be complex (including their toString()).

"if (log.isDebugEnabled())" statements are missing.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 08:52:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 08:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3601) Switch copyright to
 RedHat Middleware LLC
In-Reply-To: <5022893.1157131903947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11762590.1159275121232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3601?page=all ]

Dimitris Andreadis closed JBAS-3601.
------------------------------------

    Resolution: Done

The new license header
/*
 * JBoss, Home of Professional Open Source.
 * Copyright 2006, Red Hat Middleware LLC, and individual contributors
 * as indicated by the @author tags. See the copyright.txt file in the
 * distribution for a full listing of individual contributors.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 */

> Switch copyright to RedHat Middleware LLC
> -----------------------------------------
>
>                 Key: JBAS-3601
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3601
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Something like:
> /*
> * JBoss, Home of Professional Open Source
> * Copyright 2006, Red Hat Middleware LLC., and individual contributors as indicated 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 09:01:01 2006
From: jira-events at jboss.com (Vineeth Varghese (JIRA))
Date: Tue, 26 Sep 2006 09:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-504) Cannot use the
 object's property named as "attributes" in a rule
Message-ID: <19252356.1159275661477.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot use the object's property named as "attributes" in a rule
----------------------------------------------------------------

                 Key: JBRULES-504
                 URL: http://jira.jboss.com/jira/browse/JBRULES-504
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions: 3.0.4
         Environment: Windows 2000 with Jdk1.5
            Reporter: Vineeth Varghese
         Assigned To: Mark Proctor
         Attachments: src.zip

The word "attributes" seem to be a keyword in JBoss Rules. Basically if I have an Object that has a property named as "attributes",  I cannot use it in the IDE or create a rulebase out of it. We end up getting the following error:-

org.drools.rule.InvalidRulePackage: unknown:9:19 Unexpected token 'attributes'

	at org.drools.rule.Package.checkValidity(Unknown Source)
	at org.drools.common.AbstractRuleBase.addPackage(Unknown Source)
	at com.sample.DroolsTest.readRule(DroolsTest.java:72)
	at com.sample.DroolsTest.main(DroolsTest.java:23)

Even the IDE highlights this as an error.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 09:07:01 2006
From: jira-events at jboss.com (Dave Caruana (JIRA))
Date: Tue, 26 Sep 2006 09:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-757) Constraint violation
 during process deletion
Message-ID: <31944793.1159276021344.JavaMail.jira@cloud.prod.atl2.jboss.com>

Constraint violation during process deletion
--------------------------------------------

                 Key: JBPM-757
                 URL: http://jira.jboss.com/jira/browse/JBPM-757
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: Windows XP, Java 5, MySQL & HSQL.
            Reporter: Dave Caruana
         Assigned To: Tom Baeyens


It's taken a while to pinpoint the exact use-case, however the following test case reproduces the issue.  I don't believe I'm incorrectly using jPDL.

The process has a start task with a task controller that writes a variable (named var1) back to the process.  Note, the process does not have var1 to start with.  Then, a local variable 'var1' is set on the start task instance and the task is ended.  

Please note, at this point, there are VariableInstances persisted without an associated token, tokenvarmap, taskinstance or processinstance.   That's potentially another side-issue, but not core to this particular deletion issue.

The second task 'step2Task' is created (no task controller associated with it).  Now, a new local variable 'var1' is set against this task instance.  The task is ended.

At this point, the process is deleted.  However, it fails with a constraint violation (from FK_VARINST_TKVARMP, in the table "JBPM_VARIABLEINSTANCE" reported in MySQL) or a general exception (reported in HSQL).

Some digging reveals that when the step2Task task instance is ended, all local variables are pushed back to the process.  However, the process already has a var1 as written explicitly by the task controller of the start task.  It seems in TaskInstance.submitVariables, the process var1 is not deleted before the task local variable replaces process variable in the process token variable map.

The following test case demonstrates the issue with the default jbpm configuration files.

import java.util.List;

import junit.framework.TestCase;

import org.jbpm.JbpmConfiguration;
import org.jbpm.JbpmContext;
import org.jbpm.db.GraphSession;
import org.jbpm.db.TaskMgmtSession;
import org.jbpm.graph.def.ProcessDefinition;
import org.jbpm.graph.exe.ProcessInstance;
import org.jbpm.graph.exe.Token;
import org.jbpm.taskmgmt.exe.TaskInstance;


public class JBPMDeleteProcessTest extends TestCase {

    static JbpmConfiguration jbpmConfiguration = null; 
    static long processId = -1L;
    static String currentTokenPath = null;

    static {
      jbpmConfiguration = JbpmConfiguration.parseXmlString(
        "<jbpm-configuration>" +
        "  <jbpm-context>" +
        "    <service name='persistence' " +
        "             factory='org.jbpm.persistence.db.DbPersistenceServiceFactory' />" + 
        "  </jbpm-context>" +
        "  <string name='resource.hibernate.cfg.xml' " +
        "          value='hibernate.cfg.xml' />" +
        "  <string name='resource.business.calendar' " +
        "          value='org/jbpm/calendar/jbpm.business.calendar.properties' />" +
        "  <string name='resource.default.modules' " +
        "          value='org/jbpm/graph/def/jbpm.default.modules.properties' />" +
        "  <string name='resource.converter' " +
        "          value='org/jbpm/db/hibernate/jbpm.converter.properties' />" +
        "  <string name='resource.action.types' " +
        "          value='org/jbpm/graph/action/action.types.xml' />" +
        "  <string name='resource.node.types' " +
        "          value='org/jbpm/graph/node/node.types.xml' />" +
        "  <string name='resource.varmapping' " +
        "          value='org/jbpm/context/exe/jbpm.varmapping.xml' />" +
        "</jbpm-configuration>"
      );
    }
    
    public void setUp() {
      jbpmConfiguration.createSchema();
    }
    
    public void tearDown() {
      jbpmConfiguration.dropSchema();
    }

    public void testDelete() {
      deployProcessDefinition();

      startProcess();
      step2TaskEnd();
      deleteProcess();
    }

    public void deployProcessDefinition() {
      ProcessDefinition processDefinition = ProcessDefinition.parseXmlString
      (
        "<process-definition name='deletetest'>" +
        "  <start-state name='start'> " +  
        "    <task name='startTask'> " +
        "      <controller> " +
        "        <variable name='var1' access='write'/> " +
        "      </controller> " +
        "    </task> " +
        "   <transition name='' to='step2'/> " +
        "  </start-state> " +
        "  <task-node name='step2'> " +
        "    <task name='step2Task'/> " +
        "    <transition name='' to='step3'/> " +
        "  </task-node>" +
        "  <task-node name='step3'> " +
        "    <task name='step3Task'/> " +
        "    <transition name='' to='end'/> " +
        "  </task-node> " +      
        "  <end-state name='end' />" +
        "</process-definition>"
      );
      
      JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
      try {
        jbpmContext.deployProcessDefinition(processDefinition);
      } finally {
        jbpmContext.close();
      }
    }

    public void startProcess() {

      JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
      try {

        GraphSession graphSession = jbpmContext.getGraphSession();
        
        ProcessDefinition processDefinition = graphSession.findLatestProcessDefinition("deletetest");
        ProcessInstance processInstance = new ProcessInstance(processDefinition);
        processId = processInstance.getId();

        TaskInstance taskInstance = processInstance.getTaskMgmtInstance().createStartTaskInstance();
        taskInstance.setVariableLocally("var1", "var1Value");
        taskInstance.end();
        Token token = taskInstance.getToken();
        currentTokenPath = token.getFullName();
        
        jbpmContext.save(processInstance);
      } finally {
        jbpmContext.close();
      }
    }

    public void step2TaskEnd() {

        JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
        try {

          GraphSession graphSession = jbpmContext.getGraphSession();
          ProcessInstance processInstance = graphSession.loadProcessInstance(processId);
          Token token = processInstance.findToken(currentTokenPath);
          TaskMgmtSession taskSession = jbpmContext.getTaskMgmtSession();
          List tasks = taskSession.findTaskInstancesByToken(token.getId());
          TaskInstance taskInstance = (TaskInstance)tasks.get(0);

          //
          // comment out the following line and it works
          //
          taskInstance.setVariableLocally("var1", "var1TaskValue");

          taskInstance.setVariableLocally("var2", "var2UpdatedValue");
          taskInstance.end();
          token = taskInstance.getToken();
          currentTokenPath = token.getFullName();
          
          jbpmContext.save(processInstance);
        } finally {
          jbpmContext.close();
        }
      }

    
    public void deleteProcess()
    {
        JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
        try {

          GraphSession graphSession = jbpmContext.getGraphSession();
          ProcessInstance processInstance = graphSession.loadProcessInstance(processId);
          graphSession.deleteProcessInstance(processInstance, true, true, true);
          //jbpmContext.save(processInstance);
        } finally {
          jbpmContext.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

        


From jira-events at jboss.com  Tue Sep 26 09:37:01 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Tue, 26 Sep 2006 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3350) NPE on web service
	deployment
Message-ID: <30766120.1159277821131.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3350?page=all ]

Remy Maucherat resolved JBAS-3350.
----------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Ok. I may remove that naming code in the future.

> NPE on web service deployment
> -----------------------------
>
>                 Key: JBAS-3350
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3350
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-5.0.0.Beta
>
>
> tdiesler at TDDELL /cygdrive/d/svn/jbossws/trunk/src/test
> $ ant -Dtest=org.jboss.test.ws.wsse.WebClientTestCase one-test
> 2006-06-29 11:02:35,953 ERROR [org.apache.catalina.startup.ContextConfig] Parse error in application web.xml file at jndi:/localhost/jbossws-wsse-rpc/WEB-INF/web.xml
> java.lang.NullPointerException
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2725)
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2751)
> 	at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060)
> 	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
> <web-app version='2.4' xmlns='http://java.sun.com/xml/ns/j2ee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd'>
>  <servlet>
>   <servlet-name>Hello</servlet-name>
>   <servlet-class>org.jboss.ws.integration.jboss.JBossServiceEndpointServlet</servlet-class>
>   <init-param>
>    <param-name>ServiceEndpointImpl</param-name>
>    <param-value>org.jboss.test.ws.wsse.HelloJavaBean</param-value>
>   </init-param>
>  </servlet>
>  <servlet>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <servlet-class>org.jboss.test.ws.wsse.RpcTestClientServlet</servlet-class>
>  </servlet>
>  <servlet-mapping>
>   <servlet-name>Hello</servlet-name>
>   <url-pattern>/Hello</url-pattern>
>  </servlet-mapping>
>  <servlet-mapping>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <url-pattern>/RpcTestClientServlet</url-pattern>
>  </servlet-mapping>
>  <service-ref>
>   <service-ref-name>service/HelloService</service-ref-name>
>   <service-interface>javax.xml.rpc.Service</service-interface>
>   <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
>   <jaxrpc-mapping-file>WEB-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
>   <port-component-ref>
>    <service-endpoint-interface>org.jboss.test.ws.wsse.Hello</service-endpoint-interface>
>   </port-component-ref>
>  </service-ref>
> </web-app>

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 09:54:40 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Tue, 26 Sep 2006 09:54:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-601) Integrate http with
	messaging
In-Reply-To: <14467485.1158813717043.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26602327.1159278880219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-601?page=all ]

Tom  Elrod updated JBREM-601:
-----------------------------

    Assignee: Ron Sigal  (was: Tom  Elrod)

> Integrate http with messaging
> -----------------------------
>
>                 Key: JBREM-601
>                 URL: http://jira.jboss.com/jira/browse/JBREM-601
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.Beta1 (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> A few changes need to be made for the http transport to work with JBossMessaging.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:17:42 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 10:17:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1950446.1159280262780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno resolved JBCACHE-777.
--------------------------------------

    Resolution: Done

The level of the CacheLoader WARN message (when using custom) regarding new CacheLoader contract has changed to INFO. The message is still needed for customers to be aware of the CacheLoader interface contract changes added with JBC 1.3.

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:29:41 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 10:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-786) errors from "OK"
 putFailFast replications
Message-ID: <1399685.1159280981956.JavaMail.jira@cloud.prod.atl2.jboss.com>

errors from "OK" putFailFast replications
-----------------------------------------

                 Key: JBCACHE-786
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-786
             Project: JBoss Cache
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani
            Priority: Optional
         Attachments: jbosscache-failfast-replicate-failure.patch

[ Although putFailFast() is deprecated, it is still used by current versions of Hibernate ]

With putFailFast(), you fairly frequently see the following situation:
 
 - a call to putFailFast() succeeds
 - the (asynchronous) replication fails due to a lock timeout, and throws an exception t
   that  is thrown is logged at level ERROR

(Much more frequently because of JBCACHE-785, but it is a legitimate situation that
doesn't indicate an error.)

This patch simply detects that case and suppresses the warning. (You might be able to
it more elegantly by bridging putFailFast() onto the options framework, but to get the
exact existing behavior of putFailFast() would take a fairly extensive patch.)



-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:29:42 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 10:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-786) errors from "OK"
 putFailFast replications
In-Reply-To: <1399685.1159280981956.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22927280.1159280982208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-786?page=all ]

Owen Taylor updated JBCACHE-786:
--------------------------------

    Attachment: jbosscache-failfast-replicate-failure.patch

> errors from "OK" putFailFast replications
> -----------------------------------------
>
>                 Key: JBCACHE-786
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-786
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Optional
>         Attachments: jbosscache-failfast-replicate-failure.patch
>
>
> [ Although putFailFast() is deprecated, it is still used by current versions of Hibernate ]
> With putFailFast(), you fairly frequently see the following situation:
>  
>  - a call to putFailFast() succeeds
>  - the (asynchronous) replication fails due to a lock timeout, and throws an exception t
>    that  is thrown is logged at level ERROR
> (Much more frequently because of JBCACHE-785, but it is a legitimate situation that
> doesn't indicate an error.)
> This patch simply detects that case and suppresses the warning. (You might be able to
> it more elegantly by bridging putFailFast() onto the options framework, but to get the
> exact existing behavior of putFailFast() would take a fairly extensive patch.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:35:41 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 26 Sep 2006 10:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-787) Documentation: Add
 a chapter on extending JBoss Cache
Message-ID: <5188557.1159281341556.JavaMail.jira@cloud.prod.atl2.jboss.com>

Documentation: Add a chapter on extending JBoss Cache
-----------------------------------------------------

                 Key: JBCACHE-787
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-787
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.0


With sections on:

  1) The SPI interface
  2) How to write your custom cache loader
  3) How to write your custom eviction policy
  4) How to write your custom transaction manager lookup
  5) How to write your custom cache listener

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:38:41 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 26 Sep 2006 10:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-788) Optimistic locking
 should not REQUIRE transactions!
Message-ID: <27121247.1159281521408.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimistic locking should not REQUIRE transactions!
---------------------------------------------------

                 Key: JBCACHE-788
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-788
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0, 1.3.0, 2.0.0
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.1.0


Makes things simpler.

TXs are only used so transaction workspaces can be stored in a transaction entry.  This workspace can just as easily be stored in ThreadLocal for non-tx calls (that just have the lifespan of a single invocation).

This will:

1) Make things a LOT quicker since we don't need 2PC for all calls.
2) Make the TxInterceptor a lot simpler
3) Allow the use of Opt Locking without a TM

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 12:16:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 26 Sep 2006 12:16:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3701)
 SystemPropertiesService does not
 properly generate server path on windows
Message-ID: <32333943.1159287401584.JavaMail.jira@cloud.prod.atl2.jboss.com>

SystemPropertiesService does not properly generate server path on windows
-------------------------------------------------------------------------

                 Key: JBAS-3701
                 URL: http://jira.jboss.com/jira/browse/JBAS-3701
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1


  <mbean code="org.jboss.varia.property.SystemPropertiesService"
    name="jboss:type=Service,name=SystemProperties">
    <attribute name="Properties" replace="false"> 
         log.file.location=${jboss.server.home.dir}/log 
    </attribute>
  </mbean>

The jboss.server.home.dir is not string replaced properly on windows.

I suspect it to be related to the Property class in the Jboss common module.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 12:59:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 26 Sep 2006 12:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-557) Possible
 failure to correctly recover persistent messages on crash
Message-ID: <27405237.1159289981627.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible failure to correctly recover persistent messages on crash
------------------------------------------------------------------

                 Key: JBMESSAGING-557
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-557
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.0.1.CR5, 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Beta1


Created based a forum report that describes failure to correctly recover persistent messages after server failure.
Need to create a specialized test and investigate.
Forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974282

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 13:02:41 2006
From: jira-events at jboss.com (jasonc411 (JIRA))
Date: Tue, 26 Sep 2006 13:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-503) Compiler
 Throwing an exception on generics
In-Reply-To: <23708343.1159199821228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16710806.1159290161943.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-503?page=comments#action_12344054 ] 
            
jasonc411 commented on JBRULES-503:
-----------------------------------

So, I found the problem, and it was with the code in the save method.  What I did find is that compiler errors are not being displayed in the console output when the they are encountered.  The compilation errors are not being displayed just a message saying that an unspecified exception was caught, I had put some debugging println s in the method collectCompilerProblems and found the problem.  That though looks to be a bug in itself.

We can close this bug and reopen another that is more specific to the real problem of compiler errors not being dumped to the console or reported as part of the exception. This affects both the eclipse plugin and the PackageBuilder users.

> Compiler Throwing an exception on generics
> ------------------------------------------
>
>                 Key: JBRULES-503
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-503
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.4
>         Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
>            Reporter: jasonc411
>         Assigned To: Mark Proctor
>
> #created on: Sep 15, 2006
> package com.ca.data.dsrules
> #list any import classes here.
> import com.ca.data.model.base.DataSourceEnum;
> import com.ca.data.model.issuer.Issuer;
> import java.util.ArrayList;
> import java.util.List;
> import com.ca.data.model.Data;
> import com.ca.data.datasubs.utils.JMSServiceLocator;
> import com.ca.data.jms.JMSTextMessageSender;
> function void save(Issuer issuer){
> 	JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
> 	Data data = new Data();
> 	List<Issuer> myIssuers = new ArrayList<Issuer>();
> 	myIssuers.add(issuer);
> 	
> 	Data.setIssuerList(myIssuers);
> 	
> 	cleanQueue.simpleSend(issuer);
> }
> rule "Persist Validated Data"
> 	agenda-group "Data In"
> 	no loop
> 	salience 1
> 	
> 	when
> 		issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
> 	then 
> 		System.out.println("Validated");
> 		save(issuer);
> end

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 13:35:44 2006
From: jira-events at jboss.com (Mark Menard (JIRA))
Date: Tue, 26 Sep 2006 13:35:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-553) PrePersist
 callback method not called if entity's primery key is null
Message-ID: <13408433.1159292144943.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-553?page=all ]

Mark Menard updated EJBTHREE-553:
---------------------------------

    Attachment: EJB3EventListener_v2.patch

This is an updated patch based on Michal's work. This patch is against hibernate-entitymanager-3.2.20.CR2.

> PrePersist callback method not called if entity's primery key is null
> ---------------------------------------------------------------------
>
>                 Key: EJBTHREE-553
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-553
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jboss-4.0.4.CR2
>            Reporter: Michal Borowiecki
>         Attachments: EJB3EventListener_v2.patch
>
>
> When an entity is persisted which does not have its primary key set (and it is not annotated with GeneratedValue annotation), the @PrePersist callback method is not invoked. 
> Instead the exception is thrown:
> Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): com.bluemedia.system.User
> 	at org.hibernate.id.Assigned.generate(Assigned.java:33)
> 	at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98)
> 	at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
> 	at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:617)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:591)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:595)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:187)
> 	... 64 more
> This is in conflict with ejb 3.0-pfd spec, which states (sec. 3.4.2) :
> "The PrePersist and PreRemove callback methods are invoked for a given entity before the respective EntityManager persist and remove operations for that entity are executed."
> Since the spec states that EntityManager's persist operation is executed after the PrePersist callback methods, setting the value of the primary key in a PrePersist callback method seems a reasonable use case.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:08:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 26 Sep 2006 14:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-558) Possible
 performance
 degradation relative to JBossMQ when using contested queues and selectors
Message-ID: <527286.1159294121642.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible performance degradation relative to JBossMQ when using contested queues and selectors
----------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-558
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-558
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR5, 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Beta1


Problem described on the forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91326

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:17:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 14:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
Message-ID: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>

Uncomment HA invokers in sample-bindings.xml
--------------------------------------------

                 Key: JBAS-3702
                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
            Reporter: Galder Zamarreno
         Assigned To: Galder Zamarreno
             Fix For: JBossAS-4.0.5.GA


Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:17:42 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 14:17:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12160486.1159294662088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3702?page=all ]

Galder Zamarreno updated JBAS-3702:
-----------------------------------

    Priority: Minor  (was: Major)

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:26:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 26 Sep 2006 14:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-559) Add a
 4.0.5.CR1 EJB3 smoke test
Message-ID: <31350343.1159295201477.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a 4.0.5.CR1 EJB3 smoke test
-------------------------------

                 Key: JBMESSAGING-559
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-559
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.0.1.CR6




-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:45:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-364) Use reflection in
 org.jboss.seam.util.Persistence
In-Reply-To: <20736586.1159029241179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8673930.1159296341790.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-364?page=all ]

Gavin King updated JBSEAM-364:
------------------------------

    Fix Version/s: 1.1
         Assignee: Gavin King

> Use reflection in org.jboss.seam.util.Persistence
> -------------------------------------------------
>
>                 Key: JBSEAM-364
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-364
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> Currently we got a hard dependence to Hibernate. We should use reflection in this class.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:47:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-332) javabeans in
 session are not distributable
In-Reply-To: <13441536.1155654861191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23586587.1159296461884.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-332?page=all ]

Gavin King updated JBSEAM-332:
------------------------------

    Fix Version/s: 1.1

> javabeans in session are not distributable
> ------------------------------------------
>
>                 Key: JBSEAM-332
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-332
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0, JBoss 4.0.4GA, Windows Server 2003, Cluster of 4 nodes on 2 machines.
>            Reporter: Keith Naas
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>         Attachments: itpa.ear, itpa.ear
>
>
> We have an application that makes use of JavaBeans for a lot of our JSF "actions".  When one of our nodes is brought down, the session should Seamlessly failover to another node.  The user is sent  to a different node, but the entire session appears to be in a clean state.   We looked through the server logs and saw the following:
> 2006-08-15 10:47:36,658 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheService] [.......] loadSession(): id: GWrcdSJEASvXSJnX6fNHNg**exception occurred during serialization: java.lang.ClassNotFoundException: No ClassLoaders found for: com.ourapp.web.beans.WorksheetBean$$EnhancerByCGLIB$$bf40374c
> All of our beans are Serializable, but it appears that there is an issue with the cache sync of the CGLib proxy classes.  This specific bean does have some service properties that are transients.  It also has properties that refer to other Web JavaBeans.  
> We will be investigating this some more, but we wanted to get this logged since it appears to be a major issue that prevents us from clustering our Seam apps.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:56:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-335)
 NullPointerException if user
 quikcly decides to click a different link or button before the page renders
In-Reply-To: <7270828.1155764675359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15721507.1159297001549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-335?page=all ]

Gavin King updated JBSEAM-335:
------------------------------

    Component/s: Core

> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-335
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-335
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
>            Reporter: Keith Naas
>            Priority: Critical
>             Fix For: 1.1
>
>
> When a user is on one of our screens, they can decide to click a link before the next page loads.  Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181.  Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().  
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.  
> Stack Trace
> java.lang.NullPointerException
> 	at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> 	at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> 	at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> 	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> .....

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:56:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-335)
 NullPointerException if user
 quikcly decides to click a different link or button before the page renders
In-Reply-To: <7270828.1155764675359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11240042.1159297001778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-335?page=all ]

Gavin King updated JBSEAM-335:
------------------------------

    Fix Version/s: 1.1
         Assignee: Gavin King

> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-335
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-335
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
>            Reporter: Keith Naas
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> When a user is on one of our screens, they can decide to click a link before the next page loads.  Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181.  Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().  
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.  
> Stack Trace
> java.lang.NullPointerException
> 	at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> 	at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> 	at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> 	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> .....

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 15:05:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 15:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3703) Update JRMPInvoker
 to not cast exported object to RemoteStub
Message-ID: <13172185.1159297541691.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JRMPInvoker to not cast exported object to RemoteStub
------------------------------------------------------------

                 Key: JBAS-3703
                 URL: http://jira.jboss.com/jira/browse/JBAS-3703
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Remoting
    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1
            Reporter: Scott M Stark
         Assigned To: Tom  Elrod
             Fix For: JBossAS-4.0.6.CR1


If one runs with the jdk5 java.rmi.server.ignoreStubClasses dynamic stub override to force the server to generate stubs for exported objects, the JRMPInvoker fails to start with the following exception:

[starksm at succubus bin]$ run.sh -D-Djava.rmi.server.ignoreStubClasses=true
=========================================================================

...

11:55:52,477 WARN  [ServiceController] Problem starting service jboss:service=invoker,type=jrmp
java.lang.ClassCastException: $Proxy13
        at org.jboss.invocation.jrmp.server.JRMPInvoker.exportCI(JRMPInvoker.java:437)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.startService(JRMPInvoker.java:359)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$1.startService(JRMPInvoker.java:136)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)

The reason is that the code creating the remote object is explictly casting the export result to a RemoteStub:

   protected void exportCI() throws Exception
   {
      this.invokerStub = (RemoteStub) UnicastRemoteObject.exportObject
         (this, rmiPort, clientSocketFactory, serverSocketFactory);
   }

even though the public contract for this stub only requires a Serializable instance. The type of the invokerStub should just be relaxed to Serializable.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 15:11:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 15:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-365) <import> in
	components.xml
Message-ID: <9866704.1159297901635.JavaMail.jira@cloud.prod.atl2.jboss.com>

<import> in components.xml
--------------------------

                 Key: JBSEAM-365
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-365
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


I hate how all the built-in components have no namespace. Lets put them all back in org.jboss.seam.core, and allow use of <import namespace="org.jboss.seam.core"/> in components.xml.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 15:42:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 15:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3704) Add a notion of
 available interfaces to org.jboss.test.util.server.*
Message-ID: <18012080.1159299761464.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a notion of available interfaces to org.jboss.test.util.server.*
--------------------------------------------------------------------

                 Key: JBAS-3704
                 URL: http://jira.jboss.com/jira/browse/JBAS-3704
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
             Fix For: JBossAS-4.0.6.CR1


An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces.

We need to add this functionality to the server startup tasks.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:18:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-108) Migrate all of
 the JBoss.com Forums data to this new Forums
In-Reply-To: <19103345.1153928592271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26846209.1159301921874.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-108?page=all ]

Ryszard Kozmik updated JBFORUMS-108:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Migrate all of the JBoss.com Forums data to this new Forums
> -----------------------------------------------------------
>
>                 Key: JBFORUMS-108
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-108
>             Project: JBoss Forums
>          Issue Type: Sub-task
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:18:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:18:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-106) Load it on a
 server for Beta Testing
In-Reply-To: <977450.1153928591749.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24348436.1159301922097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-106?page=all ]

Ryszard Kozmik updated JBFORUMS-106:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Load it on a server for Beta Testing
> ------------------------------------
>
>                 Key: JBFORUMS-106
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-106
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-126) NewTopic on
 ForumsView doesn't work on IE
In-Reply-To: <7318128.1159042381055.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3468292.1159302102077.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-126?page=all ]

Ryszard Kozmik updated JBFORUMS-126:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> NewTopic on ForumsView doesn't work on IE
> -----------------------------------------
>
>                 Key: JBFORUMS-126
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-126
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Beta
>
>
> Creating topic by NewTopic button on ForumsView is not possible when browsing Forums using IE.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-83) Write User and
 Administration Guide
Message-ID: <31171798.1159302102240.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-83?page=all ]

Ryszard Kozmik updated JBFORUMS-83:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Write User and Administration Guide
> -----------------------------------
>
>                 Key: JBFORUMS-83
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-83
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Documentation, Portlet Productization
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Damon Sicore
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> Create and write a JBoss Forums User and Admin Guide.
> I suspect we only need to combine the Admin and User guide into one due to the size of this project (i.e., it's small).
> Specifically:
> * JBoss Forums Deployment Packaging.
> * Deployment Steps
> * User Administration
> * Forum and Topic Administration
> * Security and Spam
> * Forum and Topic User Instructions

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-92) UTF-8 doesn't work
 in topic subjects
Message-ID: <28369045.1159302102786.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-92?page=all ]

Ryszard Kozmik updated JBFORUMS-92:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> UTF-8 doesn't work in topic subjects
> ------------------------------------
>
>                 Key: JBFORUMS-92
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-92
>             Project: JBoss Forums
>          Issue Type: Bug
>            Reporter: Tomasz Szymanski
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> http://65.244.175.213:8080/portal-forums/views/index.jsf
> shows some silly chars instead of polish diacritic letters.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-103) Try to fix the
 followind issue
 in http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3959142#3959142
In-Reply-To: <30458909.1153317971362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15950960.1159302102915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-103?page=all ]

Ryszard Kozmik updated JBFORUMS-103:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Try to fix the followind issue in http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3959142#3959142
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBFORUMS-103
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-103
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>             Fix For: 1.0.0 Beta
>
>
> Seems like there are special characters in the post that are messing up the post display on the forums in JBoss.com
> Funny this if there was an issue with the code parser there would be a problem of showing the posts even in the post reply screen, but that screen is fine.
> Need to make sure this same error does not crop up in the new Forums

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-84) Package and Add to
	Portlet Swap
Message-ID: <23252225.1159302103070.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-84?page=all ]

Ryszard Kozmik updated JBFORUMS-84:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Package and Add to Portlet Swap
> -------------------------------
>
>                 Key: JBFORUMS-84
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-84
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Portlet Productization
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Damon Sicore
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> Add JBoss Forums to Portlet Swap.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-115) NPE in ViewTopic
In-Reply-To: <1960202.1154560871633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25451023.1159302103273.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-115?page=all ]

Ryszard Kozmik updated JBFORUMS-115:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> NPE in ViewTopic
> ----------------
>
>                 Key: JBFORUMS-115
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-115
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>          Time Spent: 2 hours, 30 minutes
>
> Clicking this link http://forums.proto.jboss.com:8080/portal/index.html?ctrl:cmd=render&ctrl:window=default.default.DefaultCMSPortletWindow&t=12&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2Fviews%2Ftopics%2Fviewtopic_body.jsf , causes whole forums to dissapear and throw this exception:
> 18:06:20,855 ERROR [[/portal-forums]] Exception in FacesServlet
> java.lang.NullPointerException
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:393)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:94)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:128)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContainer.java:521)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.java:433)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInvocation.java:79)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.component.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.component.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.NavigationInterceptor.invoke(NavigationInterceptor.java:76)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.CacheInterceptor.invoke(CacheInterceptor.java:111)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ModesInterceptor.invoke(ModesInterceptor.java:88)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:87)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPostDispatchInterceptor.invoke(SessionPostDispatchInterceptor.java:65)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:129)
>         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.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:101)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
>         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>         at org.jboss.portal.server.app.impl.AbstractRequestContext.include(AbstractRequestContext.java:247)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:73)
>         at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:81)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:79)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPreDispatchInterceptor.invoke(SessionPreDispatchInterceptor.java:94)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.ValveInterceptor.invoke(ValveInterceptor.java:64)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:84)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:68)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:141)
>         at org.jboss.portal.core.command.RenderPageCommand.renderPortlets(RenderPageCommand.java:231)
>         at org.jboss.portal.core.command.RenderPageCommand.execute(RenderPageCommand.java:164)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:58)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:93)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:151)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:77)
>         at org.jboss.portal.core.CoreController.handle(CoreController.java:190)
>         at sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
>         at $Proxy136.handle(Unknown Source)
>         at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:76)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.server.SubjectAssociationInterceptor.invoke(SubjectAssociationInterceptor.java:47)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.PolicyAssociationInterceptor.invoke(PolicyAssociationInterceptor.java:52)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:69)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:184)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:87)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java:75)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:221)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-119) Links to last
 post on all views are not working correctly
In-Reply-To: <30379171.1157039900135.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24666659.1159302103438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-119?page=all ]

Ryszard Kozmik updated JBFORUMS-119:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Links to last post on all views are not working correctly
> ---------------------------------------------------------
>
>                 Key: JBFORUMS-119
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-119
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> All links to last post do not care about paging. So, if there is more than one page in TopicView then Last Post links are pointing wrongly always to first page not to the page containing this post. Moreover permament link to post on TopicView is too long and must be shortened plus must care about paging too.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:24:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-85) Identify and
 Define Training Materials for Portal Training
Message-ID: <6318516.1159302281609.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-85?page=all ]

Ryszard Kozmik updated JBFORUMS-85:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Identify and Define Training Materials for Portal Training
> ----------------------------------------------------------
>
>                 Key: JBFORUMS-85
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-85
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Documentation, Portlet Productization
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Damon Sicore
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> At a minimum, we need to at least identify the relationships with JBoss Portal training and where JBoss Forums administration and usage concepts are required.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:24:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-123) On preview topic
 view "Powered by JBoss Portal" tag flies around
In-Reply-To: <4351983.1159037881234.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23199987.1159302281759.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-123?page=all ]

Ryszard Kozmik updated JBFORUMS-123:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> On preview topic view "Powered by JBoss Portal" tag flies around
> ----------------------------------------------------------------
>
>                 Key: JBFORUMS-123
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-123
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Beta
>
>
> While creating topic with preview the theme tag "Powered by JBoss Portal / Theme by ***" flies over forums.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:30:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 16:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-134) Update the property
	manager xsd
Message-ID: <16916820.1159302641456.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update the property manager xsd
-------------------------------

                 Key: JBTM-134
                 URL: http://jira.jboss.com/jira/browse/JBTM-134
             Project: JBoss Transaction Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Release
            Reporter: Mark Little
         Assigned To: Mark Little


The schemas for the property manager are out of date.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:33:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 16:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-92) Print error message
 when prepare fails in XAResource
Message-ID: <7422398.1159302821708.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-92?page=all ]

Mark Little reassigned JBTM-92:
-------------------------------

    Assignee: Mark Little  (was: Jonathan Halliday)

> 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.4
>
>
> 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

        


From jira-events at jboss.com  Tue Sep 26 18:21:41 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Tue, 26 Sep 2006 18:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-560) Support all
 JBossMQ equivalent JMX functionality
Message-ID: <12497178.1159309301592.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support all JBossMQ equivalent JMX functionality
------------------------------------------------

                 Key: JBMESSAGING-560
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-560
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
             Fix For: 1.2.0.Beta1


For 1.2 we need to ensure we support the same or equivalent set of management functionality as JBoss MQ.




-- 
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

        


From jira-events at jboss.com  Tue Sep 26 18:42:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 18:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3705) Fixes included in
 JBAS-3689 for
 allowing the NamingService to work correctly in multi-homed environments
 need to be incorporated.
Message-ID: <11299157.1159310561613.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 
----------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3705
                 URL: http://jira.jboss.com/jira/browse/JBAS-3705
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA


Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 18:48:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 18:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-130) Add JBoss Forums
 to Portal demo.
Message-ID: <21653339.1159310921646.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add JBoss Forums to Portal demo.
--------------------------------

                 Key: JBFORUMS-130
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-130
             Project: JBoss Forums
          Issue Type: Task
            Reporter: Ryszard Kozmik
         Assigned To: Roy Russo
            Priority: Minor
             Fix For: 1.0.0 Beta


It would be cool to have Forums deployed on JBoss Portal demo - http://portal.demo.jboss.com/ .

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 19:27:41 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Tue, 26 Sep 2006 19:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2696) Support other
 prepare[Statement|Call] methods
Message-ID: <1111910.1159313261712.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2696?page=comments#action_12344076 ] 
            
Weston Price commented on JBAS-2696:
------------------------------------

This looks done. Can we close this? 


> Support other prepare[Statement|Call] methods
> ---------------------------------------------
>
>                 Key: JBAS-2696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2696
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Adrian Brock
>
> Add support for other prepare[Statement|Call] methods.
> This will be more difficult since they are JDK1.4/JDBC3 which might not necessarily
> be supported by all drivers. e.g. result set Holdability.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 19:45:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 19:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3705) Fixes included in
 JBAS-3689 for
 allowing the NamingService to work correctly in multi-homed environments
 need to be incorporated.
In-Reply-To: <11299157.1159310561613.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <292415.1159314341606.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3705?page=all ]

Scott M Stark closed JBAS-3705.
-------------------------------

    Resolution: Done

Updated http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingSerivceMBean with new UseGlobalService attribute.


> Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3705
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3705
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 21:39:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 21:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3464) Add a wiki page
 explaining the implication of buddy replication for ClusteredSSO
In-Reply-To: <20154635.1154661372034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4551412.1159321181665.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3464?page=all ]

Brian Stansberry closed JBAS-3464.
----------------------------------

    Resolution: Done

Wiki page is http://wiki.jboss.org/wiki/Wiki.jsp?page=BuddyReplicationAndClusteredSSO

> Add a wiki page explaining the implication of buddy replication for ClusteredSSO
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3464
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3464
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> Buddy replication is not particularly appropriate for SSO.  See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=88102 for details.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:30:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 26 Sep 2006 22:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-657) StatefulBean
 passivation is broken (ClassCastException in
 org.jboss.ejb3.stateful.NestedStatefulBeanContext)
In-Reply-To: <28564339.1153417331413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15326210.1159324241867.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-657?page=all ]

Ben Wang resolved EJBTHREE-657.
-------------------------------

    Resolution: Done
      Assignee: Ben Wang

This should be fixed already in 4.0.5 and head. See EJBTHREE-612, 603, and 660. Unfortuntately, becuase of dependency on JBossCache release version (need 1.4), the latest EJB3 release doesn't contain these fixes. RC10 should have it though as long as 4.0.5 is out.

> StatefulBean passivation is broken (ClassCastException in org.jboss.ejb3.stateful.NestedStatefulBeanContext)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-657
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-657
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Ben Wang
>            Priority: Critical
>
> StatefulBean passivation is broken, because there is a conflict between what gets serialized (attribute contains) and what gets unserialized (attribute beanMO).
> 11:41:37,109 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.util.ArrayList
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.ejb3.stateful.NestedStatefulBeanContext.readExternal(Neste
> dStatefulBeanContext.java:60)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.persister.ExternalizePersister.readData(Externalize
> Persister.java:72)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectD
> escriptionFromStreaming(ObjectDescriptorFactory.java:411)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromD
> escription(ObjectDescriptorFactory.java:81)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectIn
> put.readObject(DataContainer.java:639)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride
> (ObjectInputStreamProxy.java:68)
> 11:41:37,109 ERROR [STDERR] 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:333)
> 11:41:37,109 ERROR [STDERR] 	at java.util.ArrayList.readObject(ArrayList.java:592)
> 11:41:37,109 ERROR [STDERR] 	... 74 more

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:33:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 26 Sep 2006 22:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-716) Add a flag to
 disable replication event notification
Message-ID: <31861900.1159324421774.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a flag to disable replication event notification
----------------------------------------------------

                 Key: EJBTHREE-716
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-716
             Project: EJB 3.0
          Issue Type: Sub-task
          Components: Clustering
            Reporter: Ben Wang


This came up from an email thread:

(1) By default, passivation events get called during replication cycle
(2) There is a config setting to disable this
(3) We should introduce JBoss-specific replication-only and passivation-only events that actually let you directly write/read the bytestream
(4) I will work to get two sets of events into the next EJB spec, ie. introduce @PreReplicate / @PostReplicate or something like that

We should now tie the replication to passivation events (there is no concrete spec but everyone else is doing it). But we should also have a flag to disable it if needs to.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:33:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 26 Sep 2006 22:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-717) Introduce
 JBoss-specific
 replication-only events that actually let you directly write/read the
 bytestream
Message-ID: <6792703.1159324421914.JavaMail.jira@cloud.prod.atl2.jboss.com>

Introduce JBoss-specific replication-only events that actually let you directly write/read the bytestream
---------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-717
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-717
             Project: EJB 3.0
          Issue Type: Sub-task
          Components: Clustering
            Reporter: Ben Wang


Again, per email discussion. Idea is to let user has a fuller control of how replication process should be for sfsb.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:48:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 22:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-789)
 DelegatingCacheLoader that can use a load balanced proxy
Message-ID: <6868317.1159325321520.JavaMail.jira@cloud.prod.atl2.jboss.com>

DelegatingCacheLoader that can use a load balanced proxy
--------------------------------------------------------

                 Key: JBCACHE-789
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-789
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Cache loaders
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 2.2.0


Using cache mode LOCAL and a DelegatingCacheLoader (aka a far-cache) has the potential to be a very performant cluster topology.  But, the far cache is a single point of failure.  Idea here is to develop an HA proxy to a cluster of far-caches; proxy pins to one far-cache, but can fail over to another if the primary target fails.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 23:03:41 2006
From: jira-events at jboss.com (Jon Stevens (JIRA))
Date: Tue, 26 Sep 2006 23:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3706) default version of
 jboss_init_redhat.sh is broken
Message-ID: <19255505.1159326221815.JavaMail.jira@cloud.prod.atl2.jboss.com>

default version of jboss_init_redhat.sh is broken
-------------------------------------------------

                 Key: JBAS-3706
                 URL: http://jira.jboss.com/jira/browse/JBAS-3706
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Jon Stevens


The jboss_init_redhat.sh script by default attempts to do a run.sh -c all which is useless given that server/all doesn't exist. It would be great to just have that -c all removed from the script. Additionally, it would be great if -c all and related server/all didn't exist that a nice error message would have been 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

        


From jira-events at jboss.com  Tue Sep 26 23:54:42 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Tue, 26 Sep 2006 23:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-2) Search Engine
Message-ID: <25230105.1159329282458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-2?page=all ]

Sohil Shah reassigned JBFORUMS-2:
---------------------------------

    Assignee: Sohil Shah

> Search Engine
> -------------
>
>                 Key: JBFORUMS-2
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-2
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Sohil Shah
>            Priority: Blocker
>             Fix For: 1.1.0 Alpha
>
>
> JBoss Forums definitely needs a search engine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 23:57:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 23:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-366) Stateful
	interceptors
Message-ID: <16507766.1159329461686.JavaMail.jira@cloud.prod.atl2.jboss.com>

Stateful interceptors
---------------------

                 Key: JBSEAM-366
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-366
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Seam interceptors should be allowed to carry state, just like EJB3 interceptors

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 23:57:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 23:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-366) Stateful interceptors
In-Reply-To: <16507766.1159329461686.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10353821.1159329461816.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-366?page=all ]

Gavin King closed JBSEAM-366.
-----------------------------

    Resolution: Done

> Stateful interceptors
> ---------------------
>
>                 Key: JBSEAM-366
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-366
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Seam interceptors should be allowed to carry state, just like EJB3 interceptors

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:00:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 27 Sep 2006 00:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-367) "page parameters"
Message-ID: <24462794.1159329641562.JavaMail.jira@cloud.prod.atl2.jboss.com>

"page parameters"
-----------------

                 Key: JBSEAM-367
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-367
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


The following:

   <page view-id="/viewContact.xhtml">
      <param name="contactId" value="#{contact.id}"/>
   </page>

defines a "page parameter".

(1) when redirecting or linking to the view-id, the parameters are automagically added
(2) before rendering the view, the parameter values are applied back to the model

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:00:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-8) Search as you type
Message-ID: <28612347.1159329641739.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-8?page=all ]

Sohil Shah reassigned JBFORUMS-8:
---------------------------------

    Assignee: Sohil Shah

> Search as you type
> ------------------
>
>                 Key: JBFORUMS-8
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-8
>             Project: JBoss Forums
>          Issue Type: Feature Request
>            Reporter: Ryan Campbell
>         Assigned To: Sohil Shah
>             Fix For: 1.1.0 Alpha
>
>
> JBoss Portal should implement something like this for reducing duplicate posts:
> http://blogs.msdn.com/jledgard/archive/2005/07/28/444531.aspx
> So that as you type a post, your subject (and maybe body) are used as search terms against the forums or other content sources.  They show up in next to your text box, so even lazy users will see the search results relevant to their post.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:03:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 27 Sep 2006 00:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-367) "page parameters"
In-Reply-To: <24462794.1159329641562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7342592.1159329821653.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-367?page=all ]

Gavin King closed JBSEAM-367.
-----------------------------

    Resolution: Done

Basically done, note that (1) only works when using <s:link> or directly returning the view-id as the outcome. note also that there are some minor lifecycle issues with (2).

> "page parameters"
> -----------------
>
>                 Key: JBSEAM-367
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-367
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> The following:
>    <page view-id="/viewContact.xhtml">
>       <param name="contactId" value="#{contact.id}"/>
>    </page>
> defines a "page parameter".
> (1) when redirecting or linking to the view-id, the parameters are automagically added
> (2) before rendering the view, the parameter values are applied back to the model

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:09:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:09:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-131) Refactor the
 PortalUtil functionality to an MBEAN approach
Message-ID: <24873096.1159330181583.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor the PortalUtil functionality to an MBEAN approach
----------------------------------------------------------

                 Key: JBFORUMS-131
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-131
             Project: JBoss Forums
          Issue Type: Task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 1.0.0 Beta


With this approach, different implementations for integrating the JSF system with JBoss Portal can be plugged in.

This will help better maintain the codebase to keep up with new portal releases

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:18:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-120) GUI for setting
 up security in JBForums
In-Reply-To: <23221067.1157042664516.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17909172.1159330721596.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-120?page=all ]

Sohil Shah reassigned JBFORUMS-120:
-----------------------------------

    Assignee: Sohil Shah

> GUI for setting up security in JBForums
> ---------------------------------------
>
>                 Key: JBFORUMS-120
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-120
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Forum Enhancements
>            Reporter: Ryszard Kozmik
>         Assigned To: Sohil Shah
>             Fix For: 1.1.0 Alpha
>
>
> We need a proper GUI for setting up security in forums. It should be much userfriendly than editing xml file.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:21:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-20) Finish bb code
	implementation
Message-ID: <8545438.1159330901805.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-20?page=all ]

Sohil Shah reassigned JBFORUMS-20:
----------------------------------

    Assignee: Ryszard Kozmik

> Finish bb code implementation
> -----------------------------
>
>                 Key: JBFORUMS-20
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-20
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Julien Viet
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.1.0 Alpha
>
>
> - [img] tag
> - [url=][/url]

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:21:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-109) BBCode support
 for standalone version
In-Reply-To: <12646323.1153947191321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8381677.1159330901932.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-109?page=all ]

Sohil Shah reassigned JBFORUMS-109:
-----------------------------------

    Assignee: Ryszard Kozmik

> BBCode support for standalone version
> -------------------------------------
>
>                 Key: JBFORUMS-109
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum Enhancements
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.1.0 Alpha
>
>
> BBCode parser is now working only in portal environment. We need make it work as a standalone too.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:24:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-125) BBCode URL Tag
	improvement
In-Reply-To: <3889348.1159038241186.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13763083.1159331081578.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-125?page=all ]

Sohil Shah reassigned JBFORUMS-125:
-----------------------------------

    Assignee: Ryszard Kozmik

> BBCode URL Tag improvement
> --------------------------
>
>                 Key: JBFORUMS-125
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-125
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Forum Enhancements
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.1.0 Alpha
>
>
> BBCode's URL tag could work similar to html "a href" style like : [url=http://www.example.com]My Example[/url]

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:24:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-17) poral 2.0 Users
 Guide Forums Portlet should be updated for new functionality
Message-ID: <17948309.1159331081755.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-17?page=all ]

Sohil Shah reassigned JBFORUMS-17:
----------------------------------

    Assignee: Ryszard Kozmik

>  poral 2.0 Users Guide Forums Portlet should be updated for new functionality
> -----------------------------------------------------------------------------
>
>                 Key: JBFORUMS-17
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-17
>             Project: JBoss Forums
>          Issue Type: Task
>         Environment: all
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>
> Portal 2.0 Users Guide - Forums Portlet chapter should be updated to describe new functionality like:
> -- polls
> -- user prefs
> -- moderators panel

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:27:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3312) LdapExtLoginModule is
 missing the first role group of a nested structure
Message-ID: <21667663.1159331261715.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3312?page=all ]

Scott M Stark closed JBAS-3312.
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                   JBossAS-5.0.0.Beta
                       (was: JBossAS-4.0.6.CR1)
       Resolution: Done
         Assignee: Scott M Stark  (was: Anil Saldhana)

The top level role is now queried for roleNameAttributeID in addition to following the roleAttributeID.

> LdapExtLoginModule is missing the first role group of a nested structure
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3312
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3312
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> When traversing through a hiearchical role structure, the first matching context does not have its role name added to the resulting subject roles.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:27:41 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Wed, 27 Sep 2006 00:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3707) HA/Failover RAR
 Functionality should be implemented in non-HA RARS.
Message-ID: <1569192.1159331261829.JavaMail.jira@cloud.prod.atl2.jboss.com>

HA/Failover RAR Functionality should be implemented in non-HA RARS.
-------------------------------------------------------------------

                 Key: JBAS-3707
                 URL: http://jira.jboss.com/jira/browse/JBAS-3707
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.6.CR1
            Reporter: Weston Price
         Assigned To: Weston Price
            Priority: Optional


The HA/DB failover functionality for JDBC RARs currently exists in seperated deployments (ha/xa rars). This functionality should be put into the regular RARs as a deployment option and not as a standalone configuration which is unnecessary. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:30:41 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Wed, 27 Sep 2006 00:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3707) HA/Failover RAR
 Functionality should be implemented in non-HA RARS.
In-Reply-To: <1569192.1159331261829.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29247229.1159331441475.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3707?page=all ]

Weston Price updated JBAS-3707:
-------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974397#3974397

> HA/Failover RAR Functionality should be implemented in non-HA RARS.
> -------------------------------------------------------------------
>
>                 Key: JBAS-3707
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3707
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.6.CR1
>            Reporter: Weston Price
>         Assigned To: Weston Price
>            Priority: Optional
>
> The HA/DB failover functionality for JDBC RARs currently exists in seperated deployments (ha/xa rars). This functionality should be put into the regular RARs as a deployment option and not as a standalone configuration which is unnecessary. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:33:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3301) LDAP/AD
 authentication "follow the memberOf chain"
Message-ID: <14932854.1159331621795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3301?page=all ]

Scott M Stark updated JBAS-3301:
--------------------------------

                Issue Type: Patch  (was: Support Patch)
                  Workflow: jira  (was: JEMS Support Case Workflow v6)
    Support Case Reference:   (was: https://network.jboss.com/jbossnetwork/restricted/caseDetail.html?caseId=50030000002QK7W)
          Patch Visibility:   (was: [Public])

> LDAP/AD authentication "follow the memberOf chain"
> --------------------------------------------------
>
>                 Key: JBAS-3301
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3301
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Rafael Van Durm
>         Assigned To: Scott M Stark
>         Attachments: ADLoginModule.java
>
>
> For LDAP authentication, there are 2 possibilities for now: 
> - org.jboss.security.auth.spi.LdapLoginModule
> - org.jboss.security.auth.spi.LdapExtLoginModule
> Both do not support (as far as I understand) the "follow the memberOf chain" style of finding role definitions ...
> For example: authentication and authorisation for raf
> CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
> would result in group membership (=roles) 
>   inf_iedereen
>   web-gevonden
> I implemented this authorisation scheme quickly and attached the code over here ...
> Maybe also interesting for other people?

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:33:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3301) LDAP/AD
 authentication "follow the memberOf chain"
Message-ID: <16472395.1159331621982.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3301?page=all ]

Scott M Stark closed JBAS-3301.
-------------------------------

    Resolution: Duplicate Issue

This patch is obsoleted by the fix in JBAS-3312, LdapExtLoginModule is missing the first role group of a nested structure

> LDAP/AD authentication "follow the memberOf chain"
> --------------------------------------------------
>
>                 Key: JBAS-3301
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3301
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Rafael Van Durm
>         Assigned To: Scott M Stark
>         Attachments: ADLoginModule.java
>
>
> For LDAP authentication, there are 2 possibilities for now: 
> - org.jboss.security.auth.spi.LdapLoginModule
> - org.jboss.security.auth.spi.LdapExtLoginModule
> Both do not support (as far as I understand) the "follow the memberOf chain" style of finding role definitions ...
> For example: authentication and authorisation for raf
> CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
> would result in group membership (=roles) 
>   inf_iedereen
>   web-gevonden
> I implemented this authorisation scheme quickly and attached the code over here ...
> Maybe also interesting for other people?

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:36:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-10) LdapExtLoginModule
 is missing the first role group of a nested structure
Message-ID: <18824737.1159331801463.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule is missing the first role group of a nested structure
------------------------------------------------------------------------

                 Key: SECURITY-10
                 URL: http://jira.jboss.com/jira/browse/SECURITY-10
             Project: JBoss Security
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


When traversing through a hiearchical role structure, the first matching context does not have its role name added to the resulting subject roles.  Duplicates JBAS-3312.


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:39:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-10) LdapExtLoginModule
 is missing the first role group of a nested structure
In-Reply-To: <18824737.1159331801463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19453492.1159331981761.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-10?page=all ]

Scott M Stark closed SECURITY-10.
---------------------------------

    Fix Version/s: 1.x
                   2.0
       Resolution: Done

> LdapExtLoginModule is missing the first role group of a nested structure
> ------------------------------------------------------------------------
>
>                 Key: SECURITY-10
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-10
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.x, 2.0
>
>
> When traversing through a hiearchical role structure, the first matching context does not have its role name added to the resulting subject roles.  Duplicates JBAS-3312.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:48:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-99) Jira Shows Real
 Name Rather than Alias After Create New Issue
In-Reply-To: <32262369.1152823031571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4296061.1159332521897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-99?page=all ]

Sohil Shah resolved JBFORUMS-99.
--------------------------------

    Resolution: Rejected

This is not a task on the Forums project

> Jira Shows Real Name Rather than Alias After Create New Issue
> -------------------------------------------------------------
>
>                 Key: JBFORUMS-99
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-99
>             Project: JBoss Forums
>          Issue Type: Bug
>         Environment: Browsing with Firefox 1.5
>            Reporter: Sascha Goldsmith
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>
> After posting a JIRA issue, I was shown a page summarizing my post.  On the left navigation area, it indicates 'author' with my real name, rather than my nic/alias.  Nearly everywhere else in the forums/site/etc., I am referred to by my alias/nic.  Having people's actual names posted seems a bit invasive from a privacy perspective.
> - Saish

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:54:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-30) Support
Message-ID: <17281039.1159332881697.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-30?page=all ]

Sohil Shah resolved JBFORUMS-30.
--------------------------------

    Resolution: Rejected

This is not a coding/documentation task to be associated with any particular software release as a feature, task, or a bug


Support is an ongoing service for the project

> Support
> -------
>
>                 Key: JBFORUMS-30
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-30
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>          Time Spent: 1 day, 2 hours, 20 minutes
>
> Answering e-mails and posts on forums.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:57:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-30) Support
Message-ID: <10464074.1159333061666.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-30?page=comments#action_12344091 ] 
            
Sohil Shah commented on JBFORUMS-30:
------------------------------------

irrespective of the release

> Support
> -------
>
>                 Key: JBFORUMS-30
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-30
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>          Time Spent: 1 day, 2 hours, 20 minutes
>
> Answering e-mails and posts on forums.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 01:15:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 01:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-17) poral 2.0 Users
 Guide Forums Portlet should be updated for new functionality
Message-ID: <23314541.1159334141733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-17?page=all ]

Sohil Shah resolved JBFORUMS-17.
--------------------------------

    Resolution: Duplicate Issue

See - http://jira.jboss.com/jira/browse/JBFORUMS-83

>  poral 2.0 Users Guide Forums Portlet should be updated for new functionality
> -----------------------------------------------------------------------------
>
>                 Key: JBFORUMS-17
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-17
>             Project: JBoss Forums
>          Issue Type: Task
>         Environment: all
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>
> Portal 2.0 Users Guide - Forums Portlet chapter should be updated to describe new functionality like:
> -- polls
> -- user prefs
> -- moderators panel

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 01:18:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 01:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-132) Integrate a
 CommandMapper from
 JBoss Portal to make the Forum links more user-friendly
Message-ID: <28657975.1159334321598.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate a CommandMapper from JBoss Portal to make the Forum links more user-friendly
--------------------------------------------------------------------------------------

                 Key: JBFORUMS-132
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-132
             Project: JBoss Forums
          Issue Type: Task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 1.1.0 Alpha




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 04:15:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 04:15:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3706) default version of
 jboss_init_redhat.sh is broken
In-Reply-To: <19255505.1159326221815.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10163429.1159344942029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3706?page=all ]

Dimitris Andreadis closed JBAS-3706.
------------------------------------

    Fix Version/s: No Release
       Resolution: Duplicate Issue
         Assignee: Dimitris Andreadis

See JBAS-3217, the config to be used can be overriden and defaults to 'default' now.

> default version of jboss_init_redhat.sh is broken
> -------------------------------------------------
>
>                 Key: JBAS-3706
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3706
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Jon Stevens
>         Assigned To: Dimitris Andreadis
>             Fix For: No Release
>
>
> The jboss_init_redhat.sh script by default attempts to do a run.sh -c all which is useless given that server/all doesn't exist. It would be great to just have that -c all removed from the script. Additionally, it would be great if -c all and related server/all didn't exist that a nice error message would have been 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

        


From jira-events at jboss.com  Wed Sep 27 04:18:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 04:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2493) English Error in the
 jboss_init_redhat.sh
Message-ID: <4092121.1159345121710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2493?page=all ]

Dimitris Andreadis closed JBAS-2493.
------------------------------------

    Fix Version/s: No Release
       Resolution: Out of Date
         Assignee: Dimitris Andreadis

It's fixed in the latest (4.0.5) script.

> English Error in the jboss_init_redhat.sh
> -----------------------------------------
>
>                 Key: JBAS-2493
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2493
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: RHEL 4 update 2
>            Reporter: Kevin Sundberg
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: No Release
>
>
> in /jboss/bin/jboss_init_redhat.sh there is an english error
> #make java is on your path
> JAVAPTH=${JAVAPTH:-"/usr/java/jdk1.5.0_05/bin"}
> should read
> #make sure java is in your path
> JAVAPTH=${JAVAPTH:-"/usr/java/jdk1.5.0_05/bin"}

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:03:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Wed, 27 Sep 2006 05:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16809279.1159347821655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3702?page=comments#action_12344095 ] 
            
Galder Zamarreno commented on JBAS-3702:
----------------------------------------

Committed for 4.0.5.GA - EJBInvokerHA and JMXInvokerHA invokers were uncommented for all server port definitions

Asking about 5.0...

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:11:41 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 27 Sep 2006 05:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-718) Application
	client deployer
Message-ID: <17171510.1159348301740.JavaMail.jira@cloud.prod.atl2.jboss.com>

Application client deployer
---------------------------

                 Key: EJBTHREE-718
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-718
             Project: EJB 3.0
          Issue Type: Task
    Affects Versions: EJB 3.0 RC10 - FD
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf


Build support for JavaEE 5 application clients (see EE.9 Application Clients)

- create a JBossXB parser for application_client_5.xsd
- create a client deployer
- create a client launcher

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:14:41 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 27 Sep 2006 05:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-718) Application
	client deployer
In-Reply-To: <17171510.1159348301740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7890562.1159348481530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-718?page=all ]

Carlo de Wolf updated EJBTHREE-718:
-----------------------------------

    Priority: Critical  (was: Major)

> Application client deployer
> ---------------------------
>
>                 Key: EJBTHREE-718
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-718
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC10 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>
> Build support for JavaEE 5 application clients (see EE.9 Application Clients)
> - create a JBossXB parser for application_client_5.xsd
> - create a client deployer
> - create a client launcher

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:14:41 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 27 Sep 2006 05:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-718) Application
	client deployer
In-Reply-To: <17171510.1159348301740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30691179.1159348481656.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-718?page=comments#action_12344096 ] 
            
Carlo de Wolf commented on EJBTHREE-718:
----------------------------------------

Parser is in revision 57228.

> Application client deployer
> ---------------------------
>
>                 Key: EJBTHREE-718
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-718
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC10 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>
> Build support for JavaEE 5 application clients (see EE.9 Application Clients)
> - create a JBossXB parser for application_client_5.xsd
> - create a client deployer
> - create a client launcher

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:56:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 05:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-135) Null pointer
 exception in JCA XATerminator recover
Message-ID: <18998459.1159351001815.JavaMail.jira@cloud.prod.atl2.jboss.com>

Null pointer exception in JCA XATerminator recover
--------------------------------------------------

                 Key: JBTM-135
                 URL: http://jira.jboss.com/jira/browse/JBTM-135
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:56:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 05:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-135) Null pointer exception
 in JCA XATerminator recover
In-Reply-To: <18998459.1159351001815.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22182885.1159351002064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-135?page=all ]

Mark Little closed JBTM-135.
----------------------------

    Resolution: Done

> Null pointer exception in JCA XATerminator recover
> --------------------------------------------------
>
>                 Key: JBTM-135
>                 URL: http://jira.jboss.com/jira/browse/JBTM-135
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 15 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 06:12:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Wed, 27 Sep 2006 06:12:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17636089.1159351961533.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3702?page=all ]

Galder Zamarreno updated JBAS-3702:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta

Jboss 5.0 still uses the httpha-invokers, including EJBInvokerHA and JMXInvokerHA.
These also need to be uncommented in trunk's sample-bindings.xml.

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 06:15:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Wed, 27 Sep 2006 06:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24723355.1159352142002.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3702?page=all ]

Galder Zamarreno resolved JBAS-3702.
------------------------------------

    Resolution: Done

Uncommented for 4.0.x and trunk

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>   Original Estimate: 1 hour
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 06:28:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 06:28:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-136) Check Windows services
Message-ID: <25459681.1159352921513.JavaMail.jira@cloud.prod.atl2.jboss.com>

Check Windows services
----------------------

                 Key: JBTM-136
                 URL: http://jira.jboss.com/jira/browse/JBTM-136
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
            Priority: Minor




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 07:30:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Wed, 27 Sep 2006 07:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2696) Support other
 prepare[Statement|Call] methods
Message-ID: <1646075.1159356641491.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2696?page=comments#action_12344102 ] 
            
Adrian Brock commented on JBAS-2696:
------------------------------------

It's not done, compare the cached (mc.prepare...)

   public PreparedStatement prepareStatement(String sql, int resultSetType, int resultSetConcurrency)
         throws SQLException
   {
      checkTransaction();
      try
      {
         return new WrappedPreparedStatement(this, mc.prepareStatement(sql, resultSetType, resultSetConcurrency));
      }
      catch (Throwable t)
      {
         throw checkException(t);
      }
   }

with the non-cached (mc.getConnection().prepare...)

   public PreparedStatement prepareStatement(String sql, int autoGeneratedKeys) throws SQLException
   {
      checkTransaction();
      try
      {
         return new WrappedPreparedStatement(this, mc.getConnection().prepareStatement(sql, autoGeneratedKeys));
      }
      catch (Throwable t)
      {
         throw checkException(t);
      }
   }


> Support other prepare[Statement|Call] methods
> ---------------------------------------------
>
>                 Key: JBAS-2696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2696
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Adrian Brock
>
> Add support for other prepare[Statement|Call] methods.
> This will be more difficult since they are JDK1.4/JDBC3 which might not necessarily
> be supported by all drivers. e.g. result set Holdability.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:20:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 08:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-29) Separate JTS/WS-T
 plugin for JBoss 5
Message-ID: <24685378.1159359641725.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-29?page=all ]

Mark Little updated JBTM-29:
----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial, Compatibility/Configuration]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration])
    Assignee: Jonathan Halliday  (was: Mark Little)

> Separate JTS/WS-T plugin for JBoss 5
> ------------------------------------
>
>                 Key: JBTM-29
>                 URL: http://jira.jboss.com/jira/browse/JBTM-29
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.6
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:23:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 08:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-116) Parameter checking
In-Reply-To: <21601302.1154698872133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7545430.1159359821824.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-116?page=all ]

Mark Little updated JBESB-116:
------------------------------

    Fix Version/s: 4.0

> Parameter checking
> ------------------
>
>                 Key: JBESB-116
>                 URL: http://jira.jboss.com/jira/browse/JBESB-116
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>
> Look at a convention like -paramname <param> for passing in parameters on the command line, rather than assuming element N in a list is param.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:38:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 08:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
Message-ID: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide unblock() callback and make changes in FLUSH to call unblock()
----------------------------------------------------------------------

                 Key: JGRP-330
                 URL: http://jira.jboss.com/jira/browse/JGRP-330
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


#1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).

#2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:38:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 08:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
In-Reply-To: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5724023.1159360721883.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-330?page=comments#action_12344108 ] 
            
Bela Ban commented on JGRP-330:
-------------------------------

Callback unblock() has been added, class UnblockEvent was created

> Provide unblock() callback and make changes in FLUSH to call unblock()
> ----------------------------------------------------------------------
>
>                 Key: JGRP-330
>                 URL: http://jira.jboss.com/jira/browse/JGRP-330
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> #1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).
> #2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:38:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 08:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-150) There are too many
 magic numbers/strings in the code
Message-ID: <2024480.1159360722469.JavaMail.jira@cloud.prod.atl2.jboss.com>

There are too many magic numbers/strings in the code
----------------------------------------------------

                 Key: JBESB-150
                 URL: http://jira.jboss.com/jira/browse/JBESB-150
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


Particularly in the property space.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:41:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 08:41:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
In-Reply-To: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27610853.1159360901992.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-330?page=all ]

Bela Ban reassigned JGRP-330:
-----------------------------

    Assignee: Vladimir Blagojevic  (was: Bela Ban)

Please make the necessary changes as discussed to call unblock() (or add an UnblockEvent to the receiver queue if pull-mode is used)

> Provide unblock() callback and make changes in FLUSH to call unblock()
> ----------------------------------------------------------------------
>
>                 Key: JGRP-330
>                 URL: http://jira.jboss.com/jira/browse/JGRP-330
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.4
>
>
> #1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).
> #2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:47:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 08:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3598) Get the 4.0.5.GA
 testsuite-1.4 (JRockit) passing
In-Reply-To: <31303322.1157127343880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15859838.1159361261873.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3598?page=comments#action_12344110 ] 
            
Dimitris Andreadis commented on JBAS-3598:
------------------------------------------

The failing UIL2JBossMQUnitTestCase in the last run, passes for me

one-test:
    [mkdir] Created dir: X:\cvs\jboss-public\jboss-4.0\testsuite\output\log
    [junit] Running org.jboss.test.jbossmq.test.UIL2JBossMQUnitTestCase
    [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 104.871 sec

BUILD SUCCESSFUL
Total time: 1 minute 51 seconds

> 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
>         Assigned To: 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

        


From jira-events at jboss.com  Wed Sep 27 08:50:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 08:50:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <20988747.1159361442100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344111 ] 
            
Dimitris Andreadis commented on JBAS-2299:
------------------------------------------

Clebert, I suppose you are not working on this?

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 09:03:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 09:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3582) Get the ejb3-4.0
 testsuite passing
In-Reply-To: <28677268.1156859718767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31736964.1159362221693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3582?page=all ]

Dimitris Andreadis updated JBAS-3582:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

I'm probably talking to myself.

> Get the ejb3-4.0 testsuite passing
> ----------------------------------
>
>                 Key: JBAS-3582
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3582
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.6.CR1
>
>
> There are currenlty 28 failures

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 10:38:42 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Wed, 27 Sep 2006 10:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3315064.1159367922656.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3693?page=all ]

Weston Price updated JBAS-3693:
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)

Fix fix version.

> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:02:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 27 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3709) Access Control on
 JMX Operations in the JMX Console[Patch]
Message-ID: <7386034.1159372961525.JavaMail.jira@cloud.prod.atl2.jboss.com>

Access Control on JMX Operations in the JMX Console[Patch]
----------------------------------------------------------

                 Key: JBAS-3709
                 URL: http://jira.jboss.com/jira/browse/JBAS-3709
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Create a patch for JBoss 3.2.3

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:14:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 12:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25642459.1159373681654.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3699?page=comments#action_12344117 ] 
            
Dimitris Andreadis commented on JBAS-3699:
------------------------------------------

According to WS team, this is going to be solved with jbossws-1.0.4 (Oct/31st), so no service pack for now.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:45:41 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 27 Sep 2006 12:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1016) Allow creation
 and deployment of WSRP portlets from descriptors
In-Reply-To: <12244662.1157064078725.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17744613.1159375541716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1016?page=all ]

Chris Laprun reassigned JBPORTAL-1016:
--------------------------------------

    Assignee: Julien Viet  (was: Chris Laprun)

> Allow creation and deployment of WSRP portlets from descriptors
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1016
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1016
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final
>
>
> Right now, the only way to deploy WSRP portlets is via the management portlet. We should be able to do this via the descriptors. Proposed solution is to evolve the -wsrp.xml file to accomodate portlet definition.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:51:41 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 27 Sep 2006 12:51:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1059) Fix Theme module
	tests
Message-ID: <15268729.1159375901621.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix Theme module tests
----------------------

                 Key: JBPORTAL-1059
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1059
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


Changes in the testsuite runner, have made the theme api tests not deploy/run.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:06:41 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 27 Sep 2006 13:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3704) Add a notion of
 available interfaces to org.jboss.test.util.server.*
In-Reply-To: <18012080.1159299761464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1720300.1159376801612.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3704?page=all ]

Ryan Campbell reassigned JBAS-3704:
-----------------------------------

    Assignee: Rajesh Rajasekaran

> Add a notion of available interfaces to org.jboss.test.util.server.*
> --------------------------------------------------------------------
>
>                 Key: JBAS-3704
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3704
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.6.CR1
>
>
> An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces.
> We need to add this functionality to the server startup tasks.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:24:41 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 13:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-606) patch to 1.4.4.GA to
 include fix for socket server thread leak
Message-ID: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>

patch to 1.4.4.GA to include fix for socket server thread leak
--------------------------------------------------------------

                 Key: JBREM-606
                 URL: http://jira.jboss.com/jira/browse/JBREM-606
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 1.4.4.GA
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
             Fix For: 1.4.5.GA


Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:27:41 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 13:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-606) patch to 1.4.4.GA
 to include fix for socket server thread leak
In-Reply-To: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9414905.1159378061844.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-606?page=comments#action_12344124 ] 
            
Tom  Elrod commented on JBREM-606:
----------------------------------

Have also back ported code change for JBREM-529 so that native socket will be re-used instead of sitting in TIME_WAIT state.

> patch to 1.4.4.GA to include fix for socket server thread leak
> --------------------------------------------------------------
>
>                 Key: JBREM-606
>                 URL: http://jira.jboss.com/jira/browse/JBREM-606
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.4.GA
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 1.4.5.GA
>
>
> Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:30:42 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 13:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-606) patch to 1.4.4.GA
 to include fix for socket server thread leak
In-Reply-To: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16519423.1159378242855.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-606?page=all ]

Tom  Elrod resolved JBREM-606.
------------------------------

    Resolution: Done

> patch to 1.4.4.GA to include fix for socket server thread leak
> --------------------------------------------------------------
>
>                 Key: JBREM-606
>                 URL: http://jira.jboss.com/jira/browse/JBREM-606
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.4.GA
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 1.4.5.GA
>
>
> Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:54:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <14951009.1159379681866.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344128 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

Common-BeanUtils is broken:

org.jboss.web.tomcat.tc5.WebAppClassLoader at 6455597
!--- class org.apache.struts.action.ActionServlet
!--- !--- [Ljava.lang.Class;@15889588
!--- !--- !--- java.lang.reflect.Method at 2653351
!--- !--- !--- !--- [Ljava.lang.reflect.Method;@14422877
!--- !--- !--- !--- !--- java.util.Hashtable$Entry at 23818829
!--- !--- !--- !--- !--- !--- [Ljava.util.Hashtable$Entry;@18693832
!--- !--- !--- !--- !--- !--- !--- java.util.Hashtable at 17102985
!---!---!---!---!---!---!---!--- StaticFieldReference private static java.util.Hashtable org.apache.commons.beanutils.MappedPropertyDescriptor.declaredMethodCache  Detail


There is a list of declaredMethods (Reflection) being referenced inside of MappedPropertyDescriptor.

BeanUtils is now being bundled with JBoss/JSF at this point.


If you want to avoid this bug for this specific application, having BeanUtils deployed within the application + classLoader isolations will make BeanUtils to keep circular references inside the classLoader what would avoid the contention.


We should look for a way to contribute a fix for apache.

Besides this reflection cache, it looks also they have a circular reference on their WeakHashMap, having the classLoader on the value. (but I'm not sure about that one).
But I know for sure BeanUtils is broken.

Dimitris, since this is a Beanutils bug, what should we do here? Close, postpone? It's your call now.

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:57:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:57:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <9946481.1159379862428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Assignee: Dimitris Andreadis  (was: Clebert Suconic)

Dimitris: I'm assigning this to you, just to you take a look on what to do next. If you want me to take a look on this again during 4.0.6, I can look at it. For now I'm assigning this to you just for you take a decision.

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:57:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:57:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <24753981.1159379862927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic reassigned JBAS-2299:
-------------------------------------

    Assignee: Clebert Suconic  (was: Dimitris Andreadis)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:57:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <23974749.1159379863774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Assignee: Dimitris Andreadis  (was: Clebert Suconic)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:00:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <7798227.1159380041920.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344130 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

I just realized Adrian's comment on BeanUtils. So I didn't discover anything new here.

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:06:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3710) WebServices leaking
	redeployment
Message-ID: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>

WebServices leaking redeployment
--------------------------------

                 Key: JBAS-3710
                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Clebert Suconic
         Assigned To: Thomas Diesler
            Priority: Blocker




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:06:41 2006
From: jira-events at jboss.com (Cutberto Ocampo (JIRA))
Date: Wed, 27 Sep 2006 14:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-732) remove process
 start link for processes without start task
In-Reply-To: <7236390.1155567977653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5585042.1159380401927.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-732?page=comments#action_12344132 ] 
            
Cutberto Ocampo commented on JBPM-732:
--------------------------------------

It would be nice to have a feature that allows process developers/designers to define an "external" interactive application to launch in case a task is executed (a la Carnot). For example, I would like to deploy a JSP in the same app server where jBPM is living, so I could execute the JSP so this (via a controller) has access to task/process instance variables.

This way, I could have the freedom to develop my own GUI's without them worrying about the complexities of business workflow (since this would be in the process, not in the JSP); the JSP would handle the complexity of validations, access to the model, etc. However, there may be a problem whenever you try to release a new version of the process, or a new version of the JSP(s), since the variables shared by both of them need to be synchronized (while designing the process and developing the JSP).

Please correct me if I'm expressing something wrong.

> remove process start link for processes without start task
> ----------------------------------------------------------
>
>                 Key: JBPM-732
>                 URL: http://jira.jboss.com/jira/browse/JBPM-732
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> a check should be added to the start new process execution list on the home page that verifies if the process has a forms.xml.  if not, the start process link should not be 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

        


From jira-events at jboss.com  Wed Sep 27 14:06:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3710) WebServices leaking
	redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10666269.1159380402097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3710?page=all ]

Clebert Suconic updated JBAS-3710:
----------------------------------

    Description: JBWS-1228 has the description for this bug

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:09:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3710) WebServices leaking
 redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23393134.1159380583632.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3710?page=comments#action_12344133 ] 
            
Clebert Suconic commented on JBAS-3710:
---------------------------------------

This bug needs to be addressed somehow. 

We have talked internally about removing the testsuite for WS and just ignore this bug on the release.

That decision has to be taken.

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:09:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3710) WebServices leaking
	redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13047071.1159380583866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3710?page=all ]

Clebert Suconic updated JBAS-3710:
----------------------------------

        Fix Version/s: JBossAS-4.0.5.GA
    Affects Version/s: JBossAS-4.0.5.CR1

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:23:42 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 14:23:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-606) patch to 1.4.4.GA
 to include fix for socket server thread leak
In-Reply-To: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30283160.1159381422339.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-606?page=comments#action_12344135 ] 
            
Tom  Elrod commented on JBREM-606:
----------------------------------

Also back ported fix for JBREM-372 (memory leak within leasing).

> patch to 1.4.4.GA to include fix for socket server thread leak
> --------------------------------------------------------------
>
>                 Key: JBREM-606
>                 URL: http://jira.jboss.com/jira/browse/JBREM-606
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.4.GA
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 1.4.5.GA
>
>
> Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:34:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 14:34:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3710) WebServices leaking
 redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21946955.1159382081567.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3710?page=comments#action_12344137 ] 
            
Dimitris Andreadis commented on JBAS-3710:
------------------------------------------

Disabling the ws tests in the testsuite is made to let us fix the rest of the testsuite, not to ignore the bug!

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:50:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 14:50:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-331) Backport
 configuration for TCP's nagling from 2.4
Message-ID: <12248647.1159383041684.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport configuration for TCP's nagling from 2.4
-------------------------------------------------

                 Key: JGRP-331
                 URL: http://jira.jboss.com/jira/browse/JGRP-331
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.2.7 SP1




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 15:05:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 15:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3711) Update to JGroups
	2.2.7.SP1
Message-ID: <16504659.1159383941683.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to JGroups 2.2.7.SP1
---------------------------

                 Key: JBAS-3711
                 URL: http://jira.jboss.com/jira/browse/JBAS-3711
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-4.0.5.GA


JGroups will release a 2.2.7.SP1 in the next day or so.  This will provide the ability to set TCP_NO_DELAY on TCP sockets. Integrate this so 4.0.5.GA can have reduced RPC call latency when using a TCP config.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 16:47:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 27 Sep 2006 16:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-11) Principal To Role
 mapping provider
Message-ID: <29447996.1159390061680.JavaMail.jira@cloud.prod.atl2.jboss.com>

Principal To Role mapping provider
----------------------------------

                 Key: SECURITY-11
                 URL: http://jira.jboss.com/jira/browse/SECURITY-11
             Project: JBoss Security
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0


We need a mechanism that will allow a user to configure a mapping of principal to roles that need to be added to the security context.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 16:56:43 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 16:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-124) implement APR
	transport
Message-ID: <14079103.1159390603510.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-124?page=all ]

Tom  Elrod updated JBREM-124:
-----------------------------

    Priority: Critical  (was: Optional)

> implement APR transport
> -----------------------
>
>                 Key: JBREM-124
>                 URL: http://jira.jboss.com/jira/browse/JBREM-124
>             Project: JBoss Remoting
>          Issue Type: Task
>          Components: transport
>    Affects Versions: 1.2.0 final
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> Need to add support of Apache APR based transport.  The APR code (from tomcat-connector project) uses native code to manage threads and sockets.  The end result is a much better performance using a NIO type approach where only have threads in use for processing data off the socket.  When socket is idle, the threads are released and the native code will callback to activate a thread to process the data.  
> This effort has already been started in JBossRemoting on a branch called apr_transport.  Will probably not be fully implemented till after 1.2.0 release.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:12:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:12:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <17315545.1159395162513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-5.0.0.Beta)

Changing to 4.0.5.GA as I expect to resolve this in next 24 hours.

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:12:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:12:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2272) Clustering unit test
 failures - TCP stack
Message-ID: <1216883.1159395162767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2272?page=all ]

Brian Stansberry updated JBAS-2272:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-5.0.0.Beta)

Changing to 4.0.5.GA as I expect to resolve this in next 24 hours.

> Clustering unit test failures - TCP stack
> -----------------------------------------
>
>                 Key: JBAS-2272
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2272
>             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-4.0.5.GA
>
>
> Resolve why we get numerous test case failures when using the tcp stack, even if as much as 2 seconds are allowed for state propagation across the cluster.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:12:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:12:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2560) Replace the
 MockHAPartition unit test with one that uses a JGroups GossipRouter
Message-ID: <19102369.1159395162905.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2560?page=all ]

Brian Stansberry updated JBAS-2560:
-----------------------------------

    Fix Version/s: JBossAS-5.0.1.CR1
                       (was: JBossAS-5.0.0.Beta)

> Replace the MockHAPartition unit test with one that uses a JGroups GossipRouter
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-2560
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2560
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.1.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:18:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2837) When using Cache
 Invalidation
 Framework don't remove from cache the specific bean that was changed
Message-ID: <18324054.1159395521991.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2837?page=all ]

Brian Stansberry updated JBAS-2837:
-----------------------------------

    Fix Version/s: No Release

Changing fix version from "None" to "No Release" as that's the version that means "not sure when, but not soon."

> When using Cache Invalidation Framework don't remove from cache the specific bean that was changed
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2837
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2837
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, EJB2
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: No Release
>
>
> Currently if an entity bean is modified, the CIF not only invalidates the cache for any local beans in the same invalidation group, but also removes the bean that was changed from the cache.  This reduces the usefulness of commit option A.
> See forum thread for details.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:21:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2790) JBento setup
	improvements
Message-ID: <22992221.1159395701552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2790?page=all ]

Brian Stansberry closed JBAS-2790.
----------------------------------

    Resolution: Rejected

The described improvements are done, but I'm closing as "Rejected" as this shouldn't be in the AS release notes -- doing it only indirectly impacts the AS.

> JBento setup improvements
> -------------------------
>
>                 Key: JBAS-2790
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2790
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> Currently tweaking aspects of the app server config for our JBento environment is a pain, as all tweaks have to be copied to the various /server/xyx folders.
> Create a config folder in the jbento dir, and store the various configurable files there.  Then in the server/xyz folders, have symlinks pointing to these files.
> Include:
> tc5-cluster-service.xml
> jgroups.jar (various releases, with a symlink pointing to the one in use)
> jboss-cache.jar (as above)
> jboss-web.xml
> log4j.xml

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:24:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:24:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2292)
 DistributedReplicantManager does
 not honor jmx service dependencies when notifiyng a node removal
Message-ID: <25269171.1159395882111.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2292?page=all ]

Brian Stansberry updated JBAS-2292:
-----------------------------------

    Fix Version/s: No Release

Fix version "No Release" means "not sure when, but not soon."

> DistributedReplicantManager does not honor jmx service dependencies when notifiyng a node removal
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2292
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2292
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Jboss 4.0.2, 
> WinXP
> JDK 1.5
>            Reporter: janssk1
>         Assigned To: Brian Stansberry
>             Fix For: No Release
>
>
> We are using some HASingletonServices. These services use the HAJNDI tree to lookup other services. 
> Both the HASingletonservices and the HAJNDI service are notified if a node (eg the master) is removed from the cluster. However, the order seems to be random. If the master goes down, the HASingletonservce seems to be notified first. It tries to start the singleton on another host. While starting, it uses the HAJNDI, but this one still tries to connect to the old server, leading to NamingExceptions. 
> Since i added a jmx depencency from the singleton service to HAJNDI, i would expect that the HAJNDI gets notified first. That would fix my problem. 
> I looked in the code of the DistributedReplicantManagerImpl and it seems that this one does not keep track of the order in which keys are registered. I quickly changed all HashMap and HashSet instantiations of this class to LinkedHashMap and LinkedHashSet instantiations, and now my problem is fixed. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3648) Need a clustered ejb
 compatibility test
In-Reply-To: <17070980.1158097117897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6106287.1159396061878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3648?page=all ]

Brian Stansberry updated JBAS-3648:
-----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> Need a clustered ejb compatibility test
> ---------------------------------------
>
>                 Key: JBAS-3648
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3648
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.8.SP1
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-3.2.8.SP2
>
>
> We need a test of a 3.2.x client talking to a 4.0.x clustered ejb to validate interop.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3502) Use
 ProcessExpiresFrequency to speed tests involving session timeout
In-Reply-To: <300803.1155154392870.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2338397.1159396062004.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3502?page=all ]

Brian Stansberry updated JBAS-3502:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.GA

> Use ProcessExpiresFrequency to speed tests involving session timeout
> --------------------------------------------------------------------
>
>                 Key: JBAS-3502
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3502
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering, Test Suite
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.GA
>
>
> Tomcat Manager impls expose a property ProcessExpiresFrequency, which controls how often the manager responds to the TC background process thread.  By default it is set to 6, which means the manager does a session cleanup every 6 cycles.  By default the thread runs every 10 secs, so that means session are expired once per minute.
> Need to add ProcessExpiresFrequency=1 to a context.xml deployed with session test webapps so we can reduce the time it takes for tests involving session expiration to complete.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3648) Need a clustered ejb
 compatibility test
In-Reply-To: <17070980.1158097117897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21379049.1159396062171.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3648?page=all ]

Brian Stansberry updated JBAS-3648:
-----------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2

> Need a clustered ejb compatibility test
> ---------------------------------------
>
>                 Key: JBAS-3648
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3648
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.8.SP1
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-3.2.8.SP2
>
>
> We need a test of a 3.2.x client talking to a 4.0.x clustered ejb to validate interop.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3647) Backport
 SingleRetryInterceptor to 3.2
In-Reply-To: <4654533.1158096992808.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33466312.1159396062361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3647?page=all ]

Brian Stansberry updated JBAS-3647:
-----------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2

> Backport SingleRetryInterceptor to 3.2
> --------------------------------------
>
>                 Key: JBAS-3647
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3647
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, EJB2
>    Affects Versions: JBossAS-3.2.8.SP1
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-3.2.8.SP2
>
>
> A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1:
> 2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException:
> org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132)
> at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143)
> at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918)
> We should backport this.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3556) Add non-integration
 based testing to cluster module
In-Reply-To: <8862893.1156352389582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7152954.1159396062506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3556?page=all ]

Brian Stansberry updated JBAS-3556:
-----------------------------------

    Fix Version/s: JBossAS-5.0.1.CR1

> Add non-integration based testing to cluster module
> ---------------------------------------------------
>
>                 Key: JBAS-3556
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3556
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>             Fix For: JBossAS-5.0.1.CR1
>
>
> All the unit tests for the AS cluster module are run via the testsuite tests-clustering target, which starts two AS instances.  This is painful and time consuming and discourages writing of simple unit tests that exercise a particular class, with no need for a larger integration.
> Need to set up a src/tests tree in the cluster module, add simple unit tests to it, and integrate that into the overall testsuite run.  The security module has this kind of setup; look to that to see how the overall testsuite integration is done.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:30:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3257) HANamingService:
 Enable definition of RmiBindAddress analogous to RmiBindPort
Message-ID: <17052358.1159396241655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3257?page=comments#action_12344163 ] 
            
Brian Stansberry commented on JBAS-3257:
----------------------------------------

Jerry, can you assign a Fix Version to this? If the answer is "no time in the next 9 months", please set Fix Version to "No Release".

> HANamingService: Enable definition of RmiBindAddress analogous to RmiBindPort
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-3257
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3257
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: Solaris, use gnu patch to apply patchfile:
> /opt/gnu/bin/patch < patch.txt
>            Reporter: Jerry Gauthier
>         Assigned To: Jerry Gauthier
>         Attachments: patch.txt
>
>
> Reported by Thomas Wenckebach - see JBCLUSTER-94
> Consider the following setting:
> In multi home cluster environments you might want to bind the HANamingService Port to a High Available (virtual) IP address, whereas the NamingService Port would be a local ("real") IP address in this case (different LANs). Note that it is strictly mandatory in this setting to also bind the RmiPort of HANamingService to a local IP address, since it is referenced internally via the system property java.rmi.server.hostname - a conceptual flaw, since it is also used for referencing the NamingService. Consequently, it is a must to bind both NamingService and HANamingService RmiPorts to the same interface. From this fact follows the necessity to bind HANamingService RmiPort to an interface different from the one used by HANamingService Port!
> Simply do the following:
> $> cd jboss-4.0.3SP1-src/cluster/src/main/org/jboss/ha/jndi
> $> /opt/gnu/bin/patch < patch.txt
> ( please find patch.txt attached! )

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:33:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3138) HAJNDI lookup fails
 intermittently from twiddle
Message-ID: <26343475.1159396421552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3138?page=all ]

Brian Stansberry updated JBAS-3138:
-----------------------------------

    Fix Version/s: No Release

Fix version "No Release" means "not sure when, but not soon."

> HAJNDI lookup fails intermittently from twiddle
> -----------------------------------------------
>
>                 Key: JBAS-3138
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3138
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, JMX, Naming
>    Affects Versions: JBossAS-5.0.0.Beta, JBossAS-4.0.4.CR2
>         Environment: This bug is present in JBoss 3.2.6 and 4.0.3. To produce setup a two node cluster, such as in the lab-clustering. This bug is reproducable on Windows XP, Linux WS3, & Solaris 10.
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: No Release
>
>
> Brian Egge reported in JBCLUSTER-83:
> Running twiddle against the HAJNDI port will sometimes fail, and sometimes work. It does not matter if you query the server which has the component, or the failover server. Both produce the same result. Using the standard JDNI port always works, if you query the correct server. Using the HAJNDI fails ~50% of the time:
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> 12:26:40,320 ERROR [Twiddle] Exec failed
> javax.management.InstanceNotFoundException: jboss.mq.destination:name=A,service=Queue is not registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
>         at org.jboss.mx.server.MBeanServerImpl.getAttributes(MBeanServerImpl.java:547)
>         at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:251)
>         at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:164)
>         at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
>         at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
>         at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>         at sun.rmi.transport.Transport$1.run(Transport.java:153)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
>         at java.lang.Thread.run(Thread.java:595)
> The JNDI port always works:
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1199 get jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1199 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> * In these examples, clust2 is running using the bind config port-01, which adds 100 to the ports. The bug is the same when on a single machine or multiple. The above examples are the same when using 1099/1100. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:33:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2440) Review use of
 HashMap vs. Map as
 a type declaration in DistributedReplicantManagerImpl
Message-ID: <17987664.1159396421794.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2440?page=all ]

Brian Stansberry updated JBAS-2440:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1

> Review use of HashMap vs. Map as a type declaration in DistributedReplicantManagerImpl
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-2440
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2440
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Jerry Gauthier
>             Fix For: JBossAS-5.0.0.CR1
>
>
> There are a lot of places in DistributedReplicantManagerImpl where variables are declared as HashMap instead of Map.  Since a number of internal members have been changed to ConcurrentReaderHashMap, this is dangerous (see JBAS-2439).  Need to review and where possible use Map instead of HashMap.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:36:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2470) Test multiple
 partitions and subsequent merges using Gossip Router
Message-ID: <33004143.1159396601624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2470?page=all ]

Brian Stansberry updated JBAS-2470:
-----------------------------------

    Fix Version/s: JBossAS-5.0.1.CR1

> Test multiple partitions and subsequent merges using Gossip Router
> ------------------------------------------------------------------
>
>                 Key: JBAS-2470
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2470
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.1.CR1
>
>
> Create tests of the merge handling of HAPartition and related classes by using a GossipRouter in the JGroups config. A split in the partition can be simulated by killing the GR, merge
> can be triggered by restarting it.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 19:48:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 27 Sep 2006 19:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
In-Reply-To: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1354393.1159400921689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1045?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1045.
-------------------------------------------

    Resolution: Done

> port OpenDS integration from JBoss AS testsuite to portal testsuite
> -------------------------------------------------------------------
>
>                 Key: JBPORTAL-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Test
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 16 minutes
>
> Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 20:54:41 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 27 Sep 2006 20:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1059) Fix Theme
	module tests
In-Reply-To: <15268729.1159375901621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25340788.1159404881652.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1059?page=all ]

Roy Russo resolved JBPORTAL-1059.
---------------------------------

    Resolution: Done

> Fix Theme module tests
> ----------------------
>
>                 Key: JBPORTAL-1059
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1059
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Changes in the testsuite runner, have made the theme api tests not deploy/run.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:42:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3712) Use TCP_NO_DELAY on
 sockets if HAPartition uses TCP
Message-ID: <8193195.1159407761620.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use TCP_NO_DELAY on sockets if HAPartition uses TCP
---------------------------------------------------

                 Key: JBAS-3712
                 URL: http://jira.jboss.com/jira/browse/JBAS-3712
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-4.0.5.GA


HAPartition makes synchronous RPC calls; to improve latency we should disabling nagling by setting the new JGroups TCP.tcp_nodelay flag to true.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:48:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3712) Use TCP_NO_DELAY on
 sockets if HAPartition uses TCP
In-Reply-To: <8193195.1159407761620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1707892.1159408121831.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3712?page=all ]

Brian Stansberry closed JBAS-3712.
----------------------------------

    Resolution: Done

> Use TCP_NO_DELAY on sockets if HAPartition uses TCP
> ---------------------------------------------------
>
>                 Key: JBAS-3712
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3712
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> HAPartition makes synchronous RPC calls; to improve latency we should disabling nagling by setting the new JGroups TCP.tcp_nodelay flag to true.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:48:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3711) Update to JGroups
	2.2.7.SP1
In-Reply-To: <16504659.1159383941683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2819693.1159408121970.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3711?page=all ]

Brian Stansberry closed JBAS-3711.
----------------------------------

    Resolution: Done

> Update to JGroups 2.2.7.SP1
> ---------------------------
>
>                 Key: JBAS-3711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3711
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> JGroups will release a 2.2.7.SP1 in the next day or so.  This will provide the ability to set TCP_NO_DELAY on TCP sockets. Integrate this so 4.0.5.GA can have reduced RPC call latency when using a TCP config.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:48:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2272) Clustering unit test
 failures - TCP stack
Message-ID: <5771277.1159408122093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2272?page=all ]

Brian Stansberry closed JBAS-2272.
----------------------------------

    Resolution: Done

> Clustering unit test failures - TCP stack
> -----------------------------------------
>
>                 Key: JBAS-2272
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2272
>             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-4.0.5.GA
>
>
> Resolve why we get numerous test case failures when using the tcp stack, even if as much as 2 seconds are allowed for state propagation across the cluster.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:51:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:51:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-1761) Clustering unit
	test failures
Message-ID: <7756624.1159408301968.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry resolved JBAS-1761.
------------------------------------

    Resolution: Done

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1761) Clustering unit
	test failures
Message-ID: <31959528.1159408482395.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1761?page=comments#action_12344182 ] 
            
Brian Stansberry commented on JBAS-1761:
----------------------------------------

Final resolution of this involved the following:

1) Remove all up and down threads from the tc5-cluster.sar TCP stack, and all but one (up) thread from the cluster-service.xml stack.  Removes random latency I'd seen that caused failures of timing sensitive tests.
2) Added TCP.tcp_nodelay to cluster-service.xml TCP stack, where having nagling enabled was leading to timeout of a test that made >10,000 synchronous RPC calls.

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <26490043.1159408482748.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Comment: was deleted

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <10504089.1159408483049.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Comment: was deleted

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <17929216.1159408483348.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Comment: was deleted

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:16:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 23:16:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3713) Full MBean lifecycle
 for HAPartition doesn't work
Message-ID: <26081580.1159413401705.JavaMail.jira@cloud.prod.atl2.jboss.com>

Full MBean lifecycle for HAPartition doesn't work
-------------------------------------------------

                 Key: JBAS-3713
                 URL: http://jira.jboss.com/jira/browse/JBAS-3713
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA


As reported by Noel Rocher in JBCLUSTER-55, HAPartition cycle : create -> start -> stop -> destroy -> create fails on 2nd create due to FarmMemberService throwing "org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'".

This is because superclass AbstractDeploymentScanner drops its ref to the deployer in destroyService().  The type passed to attribute Deployer is actually an ObjectName, so solution is to cache the ObjectName in FarmMemberService, and use it in createService() to re-call setDeployer() if the deployer is no longer available. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:21:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 23:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3713) Full MBean lifecycle
 for HAPartition doesn't work
In-Reply-To: <26081580.1159413401705.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14915566.1159413701622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3713?page=all ]

Brian Stansberry closed JBAS-3713.
----------------------------------

    Resolution: Done

> Full MBean lifecycle for HAPartition doesn't work
> -------------------------------------------------
>
>                 Key: JBAS-3713
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3713
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> As reported by Noel Rocher in JBCLUSTER-55, HAPartition cycle : create -> start -> stop -> destroy -> create fails on 2nd create due to FarmMemberService throwing "org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'".
> This is because superclass AbstractDeploymentScanner drops its ref to the deployer in destroyService().  The type passed to attribute Deployer is actually an ObjectName, so solution is to cache the ObjectName in FarmMemberService, and use it in createService() to re-call setDeployer() if the deployer is no longer available. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:27:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 23:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-55) Full MBean cycle
 for HAPartition doesn't work
Message-ID: <14199710.1159414061672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-55?page=all ]

Brian Stansberry resolved JBCLUSTER-55.
---------------------------------------

    Fix Version/s:     (was: Bugs)
       Resolution: Duplicate Issue
         Assignee: Brian Stansberry

Closing as duplicate; I recreated (and closed as fixed) the same issue in the AS project. Please report AS issues in the AS project.

> Full MBean cycle for HAPartition doesn't work
> ---------------------------------------------
>
>                 Key: JBCLUSTER-55
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-55
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Noel Rocher
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> HAPartition cycle : create -> start -> stop -> destroy -> create.
> Here is a stack strace on 3.2:
> 09:03:03,523 ERROR [EntityContainer] Initialization failed jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB
> java.lang.NullPointerException
>         at org.jboss.ejb.EntityContainer.createService(EntityContainer.java:236)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> 09:03:03,523 WARN  [ServiceController] Problem creating service jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB
> RuntimeMBeanException: java.lang.NullPointerException
> Cause: java.lang.NullPointerException
>         at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:82)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb.EntityContainer.createService(EntityContainer.java:236)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         ... 66 more
> 09:03:03,533 ERROR [FarmMemberService] Initialization failed jboss:service=FarmMember,partition=DefaultPartition
> org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.createService(AbstractDeploymentScanner.java:233)
>         at org.jboss.ha.framework.server.FarmMemberService.createService(FarmMemberService.java:115)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> 09:03:03,543 WARN  [ServiceController] Problem creating service jboss:service=FarmMember,partition=DefaultPartition
> MBeanException: org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
> Cause: org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
>         at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:91)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> Caused by: org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.createService(AbstractDeploymentScanner.java:233)
>         at org.jboss.ha.framework.server.FarmMemberService.createService(FarmMemberService.java:115)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         ... 66 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:30:41 2006
From: jira-events at jboss.com (warren crossing (JIRA))
Date: Wed, 27 Sep 2006 23:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3714) EjbHome.create throws
 ClassCastException
Message-ID: <16949415.1159414241894.JavaMail.jira@cloud.prod.atl2.jboss.com>

EjbHome.create throws ClassCastException
----------------------------------------

                 Key: JBAS-3714
                 URL: http://jira.jboss.com/jira/browse/JBAS-3714
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: IIOP service
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
         Environment: Java 1.5.0_08
            Reporter: warren crossing
         Assigned To: Francisco Reverbel


Hello

Please have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974096#3974096 as this sums up my issue.

I have a jboss.log file and am happy to patch the source code and test/debug this issue.

It looks as though the IOR stream to object is returning a org.jacorb.orb.Reference which does not implement the beans Remote interface. 

I have stepped through the iiop EjbObjectServant code and IORFactory, the everything looks fine, no amount of changing jboss.xml ro standardjboss.xml makes any difference.

Why possibly could the reference returned by the DynamicIIOPStub.invoke not implement the Bean Remote interface? 

Any idea, or hist of where to look/debug?


-- 
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

        


From c15 at fullmailmarket.com  Thu Sep 28 02:02:31 2006
From: c15 at fullmailmarket.com (Carrier 179)
Date: Thu, 28 Sep 2006 02:02:31 -0400
Subject: [jboss-jira] Que el precio no se lo impida!
Message-ID: <200609280602.k8S62VU5031015@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060928/3075ba60/attachment.html 

From jira-events at jboss.com  Thu Sep 28 03:21:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 28 Sep 2006 03:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-331) Backport
 configuration for TCP's nagling from 2.4
In-Reply-To: <12248647.1159383041684.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23404675.1159428101476.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-331?page=all ]

Bela Ban resolved JGRP-331.
---------------------------

    Resolution: Done

> Backport configuration for TCP's nagling from 2.4
> -------------------------------------------------
>
>                 Key: JGRP-331
>                 URL: http://jira.jboss.com/jira/browse/JGRP-331
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.2.7 SP1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:15:41 2006
From: jira-events at jboss.com (Ronald van Kuijk (JIRA))
Date: Thu, 28 Sep 2006 05:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-732) remove process
 start link for processes without start task
In-Reply-To: <7236390.1155567977653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17002937.1159434941482.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-732?page=comments#action_12344196 ] 
            
Ronald van Kuijk commented on JBPM-732:
---------------------------------------

you can if you develop your own taskcontroler 

> remove process start link for processes without start task
> ----------------------------------------------------------
>
>                 Key: JBPM-732
>                 URL: http://jira.jboss.com/jira/browse/JBPM-732
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> a check should be added to the start new process execution list on the home page that verifies if the process has a forms.xml.  if not, the start process link should not be 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

        


From jira-events at jboss.com  Thu Sep 28 05:27:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 05:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
Message-ID: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>

Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
--------------------------------------------------------------------------------------------

                 Key: JBRULES-505
                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions: 3.0.4
         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
            Reporter: Matt Green
         Assigned To: Mark Proctor


SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
key                                                                                eventTypeDiscriminator
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58         net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57          net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56          net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()



-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:29:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 05:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12543486.1159435781512.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-505?page=all ]

Matt Green updated JBRULES-505:
-------------------------------

    Description: 
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
KEY, EVENTTYPEDISCRIMINATOR
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()



  was:
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
key                                                                                eventTypeDiscriminator
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58         net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57          net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56          net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()




> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:32:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 05:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24946684.1159435961888.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-505?page=all ]

Matt Green updated JBRULES-505:
-------------------------------

    Description: 
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
KEY, EVENTTYPEDISCRIMINATOR
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent

GLOBAL variable
eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()



  was:
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
KEY, EVENTTYPEDISCRIMINATOR
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()




> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> GLOBAL variable
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:32:42 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 28 Sep 2006 05:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
In-Reply-To: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9069460.1159435962133.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-330?page=all ]

Bela Ban resolved JGRP-330.
---------------------------

    Resolution: Done

block() and unblock() are called correctly

> Provide unblock() callback and make changes in FLUSH to call unblock()
> ----------------------------------------------------------------------
>
>                 Key: JGRP-330
>                 URL: http://jira.jboss.com/jira/browse/JGRP-330
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.4
>
>
> #1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).
> #2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:35:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 28 Sep 2006 05:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3714) EjbHome.create throws
 ClassCastException
In-Reply-To: <16949415.1159414241894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19970109.1159436141792.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3714?page=all ]

Adrian Brock closed JBAS-3714.
------------------------------

    Resolution: Incomplete Description
      Assignee:     (was: Francisco Reverbel)

Just because you don't get an answer in the forums
it does not mean it is a bug report.

Also you should not use the development forums to ask for help.
Development forums are to discuss solutions to problems, not ask
for help on problems.

I'm going to move your post to the EJB user forum and ignore it.
You cannot use bug reports to jump the help queue!
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHelp

> EjbHome.create throws ClassCastException
> ----------------------------------------
>
>                 Key: JBAS-3714
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3714
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>         Environment: Java 1.5.0_08
>            Reporter: warren crossing
>
> Hello
> Please have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974096#3974096 as this sums up my issue.
> I have a jboss.log file and am happy to patch the source code and test/debug this issue.
> It looks as though the IOR stream to object is returning a org.jacorb.orb.Reference which does not implement the beans Remote interface. 
> I have stepped through the iiop EjbObjectServant code and IORFactory, the everything looks fine, no amount of changing jboss.xml ro standardjboss.xml makes any difference.
> Why possibly could the reference returned by the DynamicIIOPStub.invoke not implement the Bean Remote interface? 
> Any idea, or hist of where to look/debug?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 06:32:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 06:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
Message-ID: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>

1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
----------------------------------------------------------------------------------

                 Key: JBAS-3715
                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-42.0.2.ELsmp 
OS Arch i386 
            Reporter: Dimitris Andreadis
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


testSRPLoginWithAuxChallenge Failure

Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

The same test passes with Sun Jdk1.4 but I believe this is due to 

jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
   local_policy.jar
   US_export_policy.jar

Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 06:36:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 06:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-86) Identify what QA and
 unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6829945.1159439801742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-86?page=all ]

Mark Little reassigned JBESB-86:
--------------------------------

    Assignee: Mark Little  (was: Tom Fennelly)

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 06:45:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 06:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22799147.1159440341523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little updated JBESB-104:
------------------------------

    Priority: Blocker  (was: Critical)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>            Priority: Blocker
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 06:48:42 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 28 Sep 2006 06:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3710) WebServices leaking
	redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9887230.1159440522167.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3710?page=all ]

Thomas Diesler resolved JBAS-3710.
----------------------------------

    Resolution: Done

Done. I tested jbossws and jbossas testsuite with jdk1.5


> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 06:48:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 06:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3524887.1159440522364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little reassigned JBESB-104:
---------------------------------

    Assignee: Kevin Conner  (was: Daniel Brum)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Blocker
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:00:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3716) failed
 org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
Message-ID: <2246804.1159441241688.JavaMail.jira@cloud.prod.atl2.jboss.com>

failed org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
-----------------------------------------------------------------------------

                 Key: JBAS-3716
                 URL: http://jira.jboss.com/jira/browse/JBAS-3716
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-42.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testStringCharArrayCredential
Failure
N/A
junit.framework.AssertionFailedError
	at org.jboss.test.security.test.JaasSecurityManagerUnitTestCase.testStringCharArrayCredential(JaasSecurityManagerUnitTestCase.java:79)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Thu Sep 28 07:00:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-123) Remove hardcoded
	class names
In-Reply-To: <1140887.1155045312458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32194858.1159441241838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-123?page=all ]

Mark Little reassigned JBESB-123:
---------------------------------

    Assignee: Mark Little  (was: Daniel Brum)

> Remove hardcoded class names
> ----------------------------
>
>                 Key: JBESB-123
>                 URL: http://jira.jboss.com/jira/browse/JBESB-123
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
>       Class oCls = Class.forName("org.jboss.soa.esb.util.BobjStdDTO");

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:06:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3716) failed
 org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
In-Reply-To: <2246804.1159441241688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10523304.1159441602140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3716?page=all ]

Dimitris Andreadis closed JBAS-3716.
------------------------------------

    Resolution: Done

Fixed the order.

> failed org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-3716
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3716
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> testStringCharArrayCredential
> Failure
> N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.security.test.JaasSecurityManagerUnitTestCase.testStringCharArrayCredential(JaasSecurityManagerUnitTestCase.java:79)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Thu Sep 28 07:06:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-123) Remove hardcoded
	class names
In-Reply-To: <1140887.1155045312458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20384745.1159441602293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-123?page=all ]

Mark Little closed JBESB-123.
-----------------------------

    Resolution: Done

> Remove hardcoded class names
> ----------------------------
>
>                 Key: JBESB-123
>                 URL: http://jira.jboss.com/jira/browse/JBESB-123
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 5 minutes
>  Remaining Estimate: 0 minutes
>
>       Class oCls = Class.forName("org.jboss.soa.esb.util.BobjStdDTO");

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:06:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-145) Automate the
 trailblazer as part of QA
In-Reply-To: <6932816.1158761999738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23293927.1159441602483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-145?page=all ]

Mark Little reassigned JBESB-145:
---------------------------------

    Assignee: Jason Lenhart  (was: Daniel Brum)

> Automate the trailblazer as part of QA
> --------------------------------------
>
>                 Key: JBESB-145
>                 URL: http://jira.jboss.com/jira/browse/JBESB-145
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Examples, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:08:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-27) Manage the wiki
 pages for consistency and traversal
Message-ID: <31737211.1159441721672.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-27?page=comments#action_12344204 ] 
            
Mark Little commented on JBESB-27:
----------------------------------

I think we are OK at the moment. This is going to be an on-going task anyway, so I'd like to close it as DONE.

> Manage the wiki pages for consistency and traversal
> ---------------------------------------------------
>
>                 Key: JBESB-27
>                 URL: http://jira.jboss.com/jira/browse/JBESB-27
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Minor
>             Fix For: 4.0
>
>
> We need to make sure that the JBossESB wiki pages are up-to-date with respect to what happens on the forums and that they all have a consistent look-and-feel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:10:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <9108980.1159441842314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Dimitris Andreadis updated JBAS-2299:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

It's too late for 3rd party updates at this point, so let's revisit this in the next release. Thanks Clebert!

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: Data.txt, SampleApp.ear
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:10:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10238028.1159441842440.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3699?page=all ]

Dimitris Andreadis updated JBAS-3699:
-------------------------------------

    Comment: was deleted

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:13:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:13:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-151) Does the
 ParamsRepository
 approach conflict with, or support, the PropertyManager?
Message-ID: <30050711.1159442021527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Does the ParamsRepository approach conflict with, or support, the PropertyManager?
----------------------------------------------------------------------------------

                 Key: JBESB-151
                 URL: http://jira.jboss.com/jira/browse/JBESB-151
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:13:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:13:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19541705.1159442021655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3699?page=comments#action_12344206 ] 
            
Dimitris Andreadis commented on JBAS-3699:
------------------------------------------

Re-enable the ws tests using the new jbossws-1.0.3SP1 update to see if it fixes the memory leak.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:16:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:16:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-73) Work out which
 classes and interfaces are private versus public
Message-ID: <4764357.1159442201788.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-73?page=comments#action_12344207 ] 
            
Mark Little commented on JBESB-73:
----------------------------------

I think ParamFileRepository can be made internal, since all users (except tests) access it via the factory.

> Work out which classes and interfaces are private versus public
> ---------------------------------------------------------------
>
>                 Key: JBESB-73
>                 URL: http://jira.jboss.com/jira/browse/JBESB-73
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:19:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:19:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-73) Work out which
 classes and interfaces are private versus public
Message-ID: <2213037.1159442381611.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-73?page=comments#action_12344208 ] 
            
Mark Little commented on JBESB-73:
----------------------------------

StreamUtils could likewise be moved because it is only used by ParamFileRepository.

> Work out which classes and interfaces are private versus public
> ---------------------------------------------------------------
>
>                 Key: JBESB-73
>                 URL: http://jira.jboss.com/jira/browse/JBESB-73
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:22:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:22:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-64) General tidy-up of
	code
Message-ID: <214473.1159442561687.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-64?page=comments#action_12344210 ] 
            
Mark Little commented on JBESB-64:
----------------------------------

Remove I from the front of interface names.

> General tidy-up of code
> -----------------------
>
>                 Key: JBESB-64
>                 URL: http://jira.jboss.com/jira/browse/JBESB-64
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Arvinder Singh
>            Priority: Minor
>             Fix For: 4.0
>
>
> 1) Naming Conventions, e.g IbatchHandler -> IBatchHandler
> 2) Property naming conventions
> 3) Categorize exceptions instead of just using Exception, e.g ConnectException, etc
> 4) import specific classes not * 

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:28:41 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Thu, 28 Sep 2006 07:28:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7704209.1159442921712.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-505?page=comments#action_12344211 ] 
            
Mark Proctor commented on JBRULES-505:
--------------------------------------

btw that example uses a "return value" instead of a "predicate". Any chance you could make a self contained test, otherwise it will be some time before we get round to testing this.

> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> GLOBAL variable
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:28:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:28:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-152) Restructure the
	action package
Message-ID: <27906295.1159442921823.JavaMail.jira@cloud.prod.atl2.jboss.com>

Restructure the action package
------------------------------

                 Key: JBESB-152
                 URL: http://jira.jboss.com/jira/browse/JBESB-152
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:34:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:34:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-153) Make all
 configuration attribute names have consistent format
Message-ID: <25928255.1159443281619.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make all configuration attribute names have consistent format
-------------------------------------------------------------

                 Key: JBESB-153
                 URL: http://jira.jboss.com/jira/browse/JBESB-153
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


org.jboss.soa.esb as the root of all names.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:40:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 07:40:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9170219.1159443641950.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-505?page=comments#action_12344212 ] 
            
Matt Green commented on JBRULES-505:
------------------------------------

OK, I'll put together some code and make it selfcontained. I will have to simplify the asserted objects as they are EJBs! I'll replace with simple Java classes.

> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> GLOBAL variable
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:49:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:49:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-111) JMX support
In-Reply-To: <22340669.1154530933941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5829812.1159444181558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-111?page=all ]

Mark Little updated JBESB-111:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> JMX support
> -----------
>
>                 Key: JBESB-111
>                 URL: http://jira.jboss.com/jira/browse/JBESB-111
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.1
>
>
> Support for JMX (the one build into java5) so you can look at the pool
> and reset connection 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

        


From jira-events at jboss.com  Thu Sep 28 08:07:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 08:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-137) JTS
 PropagationContextManager does too much
Message-ID: <5466271.1159445261544.JavaMail.jira@cloud.prod.atl2.jboss.com>

JTS PropagationContextManager does too much
-------------------------------------------

                 Key: JBTM-137
                 URL: http://jira.jboss.com/jira/browse/JBTM-137
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.6


We should only need to send a reference to the current transaction and not the full context. Also means we don't need to do interposition, just resume.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 08:43:41 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Thu, 28 Sep 2006 08:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-154) Change configuration
 for FTP listeners/actions to avoid need to replicate FTP parameters
Message-ID: <4026448.1159447421501.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change configuration for FTP listeners/actions to avoid need to replicate FTP parameters
----------------------------------------------------------------------------------------

                 Key: JBESB-154
                 URL: http://jira.jboss.com/jira/browse/JBESB-154
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0
            Reporter: Esteban Schifman
         Assigned To: Esteban Schifman
            Priority: Minor


FTP server/username/password are needed both by the RemoteDirectoryPoller, and the FTP classes
As it stands now, they need to be replicated in the xml configuration file for listeners and actions.  This is not appropriate and we should find ways to avoid this need.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:07:41 2006
From: jira-events at jboss.com (David Fuelling (JIRA))
Date: Thu, 28 Sep 2006 09:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAIL-250)
 MailUserImpl.getAliases(..)
 throws an NPE if there is no mailbox for a given alias to check.
Message-ID: <3262166.1159448861705.JavaMail.jira@cloud.prod.atl2.jboss.com>

MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.
--------------------------------------------------------------------------------------------

                 Key: JBMAIL-250
                 URL: http://jira.jboss.com/jira/browse/JBMAIL-250
             Project: JBoss Mail
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Mail Server APIs
    Affects Versions: 1.0-M5, 1.0-RC1
         Environment: WinXp, Jdk 1.5
            Reporter: David Fuelling
         Assigned To: Andrew Oliver
            Priority: Minor


MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).

Here is my patch:



Index: MailSenderImpl.java
===================================================================
RCS file: /cvsroot/jboss/jboss-mail/src/java/org/jboss/mail/userapi/MailSenderImpl.java,v
retrieving revision 1.13
diff -u -r1.13 MailSenderImpl.java
--- MailSenderImpl.java	13 Jun 2006 23:53:04 -0000	1.13
+++ MailSenderImpl.java	28 Sep 2006 13:05:06 -0000
@@ -273,6 +273,9 @@
     @Tx(TxType.REQUIRED)
     public List<String> getAliases(String user) {
         Mailbox box = this.mailboxService.getMailboxByAlias(user);
+        if(box == null)
+        	return new ArrayList<String>(); //No Aliases exist for this user.
+        
         Collection<Alias> a = box.getAliases();
         List<String> l = new ArrayList<String>(a.size());
         Iterator<Alias> i = a.iterator();

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:10:41 2006
From: jira-events at jboss.com (David Fuelling (JIRA))
Date: Thu, 28 Sep 2006 09:10:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMAIL-250)
 MailUserImpl.getAliases(..)
 throws an NPE if there is no mailbox for a given alias to check.
In-Reply-To: <3262166.1159448861705.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14356141.1159449041981.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMAIL-250?page=all ]

David Fuelling updated JBMAIL-250:
----------------------------------

    Attachment: MailSenderImpl_patch..txt

This is the patch file for this issue.

> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMAIL-250
>                 URL: http://jira.jboss.com/jira/browse/JBMAIL-250
>             Project: JBoss Mail
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Mail Server APIs
>    Affects Versions: 1.0-M5, 1.0-RC1
>         Environment: WinXp, Jdk 1.5
>            Reporter: David Fuelling
>         Assigned To: Andrew Oliver
>            Priority: Minor
>         Attachments: MailSenderImpl_patch..txt
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).
> Here is my patch:
> Index: MailSenderImpl.java
> ===================================================================
> RCS file: /cvsroot/jboss/jboss-mail/src/java/org/jboss/mail/userapi/MailSenderImpl.java,v
> retrieving revision 1.13
> diff -u -r1.13 MailSenderImpl.java
> --- MailSenderImpl.java	13 Jun 2006 23:53:04 -0000	1.13
> +++ MailSenderImpl.java	28 Sep 2006 13:05:06 -0000
> @@ -273,6 +273,9 @@
>      @Tx(TxType.REQUIRED)
>      public List<String> getAliases(String user) {
>          Mailbox box = this.mailboxService.getMailboxByAlias(user);
> +        if(box == null)
> +        	return new ArrayList<String>(); //No Aliases exist for this user.
> +        
>          Collection<Alias> a = box.getAliases();
>          List<String> l = new ArrayList<String>(a.size());
>          Iterator<Alias> i = a.iterator();

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:10:42 2006
From: jira-events at jboss.com (Luca Stancapiano (JIRA))
Date: Thu, 28 Sep 2006 09:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16298248.1159449042466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3690?page=comments#action_12344218 ] 
            
Luca Stancapiano commented on JBAS-3690:
----------------------------------------

in that test, JSESSIONIDSSO seems to not be catched......after the search of cookies , test fails because is not there that cookie

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:10:42 2006
From: jira-events at jboss.com (David Fuelling (JIRA))
Date: Thu, 28 Sep 2006 09:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMAIL-250)
 MailUserImpl.getAliases(..)
 throws an NPE if there is no mailbox for a given alias to check.
In-Reply-To: <3262166.1159448861705.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22115920.1159449042658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMAIL-250?page=all ]

David Fuelling updated JBMAIL-250:
----------------------------------

    Description: 
MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).

See the attached file for proposed patch.

  was:
MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).

Here is my patch:



Index: MailSenderImpl.java
===================================================================
RCS file: /cvsroot/jboss/jboss-mail/src/java/org/jboss/mail/userapi/MailSenderImpl.java,v
retrieving revision 1.13
diff -u -r1.13 MailSenderImpl.java
--- MailSenderImpl.java	13 Jun 2006 23:53:04 -0000	1.13
+++ MailSenderImpl.java	28 Sep 2006 13:05:06 -0000
@@ -273,6 +273,9 @@
     @Tx(TxType.REQUIRED)
     public List<String> getAliases(String user) {
         Mailbox box = this.mailboxService.getMailboxByAlias(user);
+        if(box == null)
+        	return new ArrayList<String>(); //No Aliases exist for this user.
+        
         Collection<Alias> a = box.getAliases();
         List<String> l = new ArrayList<String>(a.size());
         Iterator<Alias> i = a.iterator();


> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMAIL-250
>                 URL: http://jira.jboss.com/jira/browse/JBMAIL-250
>             Project: JBoss Mail
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Mail Server APIs
>    Affects Versions: 1.0-M5, 1.0-RC1
>         Environment: WinXp, Jdk 1.5
>            Reporter: David Fuelling
>         Assigned To: Andrew Oliver
>            Priority: Minor
>         Attachments: MailSenderImpl_patch..txt
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).
> See the attached file for proposed patch.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:24:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 28 Sep 2006 10:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4499762.1159453481937.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3690?page=comments#action_12344219 ] 
            
Brian Stansberry commented on JBAS-3690:
----------------------------------------

If you want to discuss the test, please open a forum thread on http://www.jboss.com/index.html?module=bb&op=viewforum&f=64.  If your JIRA issue includes "(I think...)" that's a good sign you shouldn't open a JIRA but rather a forum thread.

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:29:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 28 Sep 2006 10:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <388796.1159453781607.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344220 ] 
            
Anil Saldhana commented on JBAS-3715:
-------------------------------------

Remember the "Unlimited Strength Crypto" that needs to be downloaded for the VM?  We did for Sun VM?

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:32:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 28 Sep 2006 10:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <5409028.1159453962270.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344221 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

We could update BeanUtils to use SoftReferences on reflection.
The easiest way to do this would be to use PersistentReference (a package I created for JBossSerialization) and recreate reflection automatically in case the SoftReference is released earlier than expected.

We could contribute PersistentReferences to Apache and use it on BeanUtils. (But I don't know if we want to do this. I know we could since I"m the author of the package)

http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: Data.txt, SampleApp.ear
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:32:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 10:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2978434.1159453962435.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344222 ] 
            
Dimitris Andreadis commented on JBAS-3715:
------------------------------------------

I remember you gave me a link to download the jars :)

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:38:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 28 Sep 2006 10:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3338126.1159454321899.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344223 ] 
            
Anil Saldhana commented on JBAS-3715:
-------------------------------------

http://java.sun.com/products/jce/index-14.html#UnlimitedDownload
This is for JDK4.  Should work on JRockit also as per http://dev.project.net/trac/pnet/wiki/InstallationGuides

(Q. Where do I get the unlimited strength encryption JCE Policy files for JRockit? A. Use the Sun ones for the appropriate version of JRockit (e.g. 1.4.2 policy files))

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:47:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 10:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6361975.1159454861866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3715?page=all ]

Dimitris Andreadis reassigned JBAS-3715:
----------------------------------------

    Assignee: Rajesh Rajasekaran  (was: Anil Saldhana)

Rajesh should take it from here, thanks Anil!

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 11:05:41 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 28 Sep 2006 11:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11574974.1159455941554.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344225 ] 
            
Rajesh Rajasekaran commented on JBAS-3715:
------------------------------------------

Have updated the unlimited strength encryption files. will wait for the next run and close the issue once test passes

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 11:35:41 2006
From: jira-events at jboss.com (Thomas Klute (JIRA))
Date: Thu, 28 Sep 2006 11:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-758) DbPersistenceService
 needs update for new Hibernate version
Message-ID: <8388143.1159457741580.JavaMail.jira@cloud.prod.atl2.jboss.com>

DbPersistenceService needs update for new Hibernate version
-----------------------------------------------------------

                 Key: JBPM-758
                 URL: http://jira.jboss.com/jira/browse/JBPM-758
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: jboss AS 4.0.4, hibernate 3.1 or hibernate 3.2
            Reporter: Thomas Klute
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3


Release of JDBC connections changed with hibernate version > 3.0.
DbPersistenceService now throws exception when trying to close a hibernate session (because in was closed automatically when the transaction committed).
The exception happens every few seconds when using the jbpm scheduler-service.
See below for stack trace.

See http://www.hibernate.org/250.html#A31 for a detailed description of hibernate-changes regarding JDBC connections.

FYI: The exception does not roll back the transaction, because it has already been committed. 
Please adapt the code to the new hibernate behaviour. Maybe just comment out the "throw" of the exception.
I have no idea what code would work with old _and_ new hibernate versions.
We just got the problem integrating jbpm into a jboss AS 4.0.4 using hibernate 3.2.


...
2006-09-28 16:11:53,996 DEBUG [org.jbpm.persistence.db.DbPersistenceService] creating hibernate session
2006-09-28 16:11:53,998 DEBUG [org.hibernate.jdbc.JDBCContext] TransactionFactory reported no active transaction; Synchronization not registered
2006-09-28 16:11:53,998 DEBUG [org.hibernate.impl.SessionImpl] opened session at timestamp: 4749118316527616
2006-09-28 16:11:53,998 DEBUG [org.jbpm.persistence.db.DbPersistenceService] beginning hibernate transaction
2006-09-28 16:11:53,998 DEBUG [org.hibernate.transaction.JTATransaction] Looking for UserTransaction under: UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] Obtained UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] begin
2006-09-28 16:11:54,000 DEBUG [org.hibernate.transaction.JTATransaction] Began a new JTA transaction
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.JDBCContext] successfully registered Synchronization
2006-09-28 16:11:54,000 DEBUG [org.jbpm.scheduler.impl.SchedulerThread] checking for timers
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection
2006-09-28 16:11:54,000 DEBUG [org.hibernate.SQL] select timer0_.ID_ as col_0_0_ from JBPM_TIMER timer0_ where (timer0_.EXCEPTION_ is null) and timer0_.ISSUSPENDED_<>1 order by timer0_.DUEDATE_ asc
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] exhausted results
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] closing iterator
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2006-09-28 16:11:54,001 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
2006-09-28 16:11:54,002 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 15a9173
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] commit
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] Committed JTA UserTransaction
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.svc.Services.close(Services.java:211)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.JbpmContext.close(JbpmContext.java:139)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
2006-09-28 16:11:54,003 ERROR [STDERR] Caused by: org.hibernate.SessionException: Session was already closed
2006-09-28 16:11:54,003 ERROR [STDERR]  at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
2006-09-28 16:11:54,003 ERROR [STDERR]  at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
2006-09-28 16:11:54,003 ERROR [STDERR]  ... 4 more
2006-09-28 16:11:54,003 ERROR [org.jbpm.svc.Services] problem closing service 'persistence'
org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
        at org.jbpm.svc.Services.close(Services.java:211)
        at org.jbpm.JbpmContext.close(JbpmContext.java:139)
        at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
        at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.hibernate.SessionException: Session was already closed
        at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
        ... 4 more
2006-09-28 16:11:54,003 INFO  [org.jbpm.scheduler.impl.SchedulerThread] runtime exception while executing timers
org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session}
        at org.jbpm.svc.Services.close(Services.java:223)
        at org.jbpm.JbpmContext.close(JbpmContext.java:139)
        at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
        at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
        at org.jbpm.svc.Services.close(Services.java:211)
        ... 3 more
Caused by: org.hibernate.SessionException: Session was already closed
        at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
        ... 4 more


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 11:38:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Thu, 28 Sep 2006 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3717) correct TCL should
 be used before starting entity PMs
Message-ID: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>

correct TCL should be used before starting entity PMs
-----------------------------------------------------

                 Key: JBAS-3717
                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky


In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
   protected void startService() throws Exception
   {
      // before EntityContainer returns from the startService, its PM should be usable
      ListIterator iter = containerOrdering.listIterator();
      while( iter.hasNext() )
      {
         Container con = (Container) iter.next();
         if(con.getBeanMetaData().isEntity())
         {
            ClassLoader oldCl = SecurityActions.getContextClassLoader();
            SecurityActions.setContextClassLoader(con.getClassLoader());

            try
            {
               ((EntityContainer)con).getPersistenceManager().start();
            }
            finally
            {
               // Reset classloader
               SecurityActions.setContextClassLoader(oldCl);
            }
         }
      }
...

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-27) Integrate Web
 Services transactions component with JBoss 4
Message-ID: <23932694.1159459361787.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-27?page=comments#action_12344226 ] 
            
Kevin Conner commented on JBTM-27:
----------------------------------

The web services component was actually integrated in release 4.2.1.

> Integrate Web Services transactions component with JBoss 4
> ----------------------------------------------------------
>
>                 Key: JBTM-27
>                 URL: http://jira.jboss.com/jira/browse/JBTM-27
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-27) Integrate Web Services
 transactions component with JBoss 4
Message-ID: <28612186.1159459361949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-27?page=all ]

Kevin Conner closed JBTM-27.
----------------------------

    Fix Version/s: 4.2.1
                       (was: 4.2.2)
       Resolution: Done

> Integrate Web Services transactions component with JBoss 4
> ----------------------------------------------------------
>
>                 Key: JBTM-27
>                 URL: http://jira.jboss.com/jira/browse/JBTM-27
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:14:43 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:14:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-117) release notes for
 JTS talk about context interceptor
In-Reply-To: <4031051.1155223512756.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3034363.1159460083461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-117?page=all ]

Kevin Conner resolved JBTM-117.
-------------------------------

    Resolution: Done

> release notes for JTS talk about context interceptor
> ----------------------------------------------------
>
>                 Key: JBTM-117
>                 URL: http://jira.jboss.com/jira/browse/JBTM-117
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Should update to talk about interposition interceptor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:14:43 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:14:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-117) release notes for JTS
 talk about context interceptor
In-Reply-To: <4031051.1155223512756.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30187869.1159460083630.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-117?page=all ]

Kevin Conner closed JBTM-117.
-----------------------------


> release notes for JTS talk about context interceptor
> ----------------------------------------------------
>
>                 Key: JBTM-117
>                 URL: http://jira.jboss.com/jira/browse/JBTM-117
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Should update to talk about interposition interceptor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:29:41 2006
From: jira-events at jboss.com (Andrew Rubinger (JIRA))
Date: Thu, 28 Sep 2006 12:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <155313.1159460981856.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12344231 ] 
            
Andrew Rubinger commented on EJBTHREE-402:
------------------------------------------

EJB3 RC9 Patch Installer for JBoss AS 4.0.4-GA does not update $JBOSS_HOME/client/jboss-ejb3.jar.

If you're running a standalone client, and this JAR is in your classpath, you will receive the deserialization errors above.  To fix, ensure your client is referencing the version of jboss-ejb3.jar found in $JBOSS_HOME/server/deploy/[instanceName]/ejb3.deployer.

S,
ALR

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:47:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 12:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-356) Session bean
	assertions
In-Reply-To: <26202711.1158784440217.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23878968.1159462061710.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-356?page=comments#action_12344234 ] 
            
Gavin King commented on JBSEAM-356:
-----------------------------------

Can also do it for method calls:

@NotNull public String doSomething(@NotNull parameter) { .... }

> Session bean assertions
> -----------------------
>
>                 Key: JBSEAM-356
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-356
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>
> For people who like more of a design-by-contract style, we could let you specify Hibernate Validator annotations on the session bean, and check them after @PostConstruct and before and after each business method.
> eg.
> @Stateful
> public class Foo {
>     @NotNull private Bar bar;
>     @Min(0) int count;
> }

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:47:41 2006
From: jira-events at jboss.com (Andrew Rubinger (JIRA))
Date: Thu, 28 Sep 2006 12:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <15580788.1159462061920.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12344235 ] 
            
Andrew Rubinger commented on EJBTHREE-402:
------------------------------------------

Correction, the patch installer does not update $JBOSS_HOME/client/jboss-ejb3-client.jar 

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:20:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <2418240.1159464041847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha2
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:26:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-516) Clustering
In-Reply-To: <13854429.1155575300086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24056857.1159464401643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-516?page=all ]

Ovidiu Feodorov updated JBMESSAGING-516:
----------------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

Container tasks, needs to be completed by Beta.

> Clustering
> ----------
>
>                 Key: JBMESSAGING-516
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-516
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>
> Implement clustering as described in:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:35:47 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-4) Load balancing
Message-ID: <1754753.1159464947507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-4?page=all ]

Ovidiu Feodorov updated JBMESSAGING-4:
--------------------------------------

    Assignee: Tim Fox

> Load balancing
> --------------
>
>                 Key: JBMESSAGING-4
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-4
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:35:47 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-4) Load balancing
Message-ID: <12742017.1159464947916.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-4?page=all ]

Ovidiu Feodorov closed JBMESSAGING-4.
-------------------------------------

    Resolution: Done

Distributed destinations are done.

> Load balancing
> --------------
>
>                 Key: JBMESSAGING-4
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-4
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:57:43 2006
From: jira-events at jboss.com (David DeGroff (JIRA))
Date: Thu, 28 Sep 2006 13:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-27) Manage the wiki pages
 for consistency and traversal
Message-ID: <2246409.1159466263651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-27?page=all ]

David DeGroff closed JBESB-27.
------------------------------

    Resolution: Done

> Manage the wiki pages for consistency and traversal
> ---------------------------------------------------
>
>                 Key: JBESB-27
>                 URL: http://jira.jboss.com/jira/browse/JBESB-27
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Minor
>             Fix For: 4.0
>
>
> We need to make sure that the JBossESB wiki pages are up-to-date with respect to what happens on the forums and that they all have a consistent look-and-feel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:14:41 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Thu, 28 Sep 2006 14:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-368) STATELESS component
 injection rules are not intuitive/undocumented
Message-ID: <30807595.1159467281452.JavaMail.jira@cloud.prod.atl2.jboss.com>

STATELESS component injection rules are not intuitive/undocumented
------------------------------------------------------------------

                 Key: JBSEAM-368
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-368
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


This is probably a non-issue, so feel free to ignore.

It took me a while to figure out why this works:

@In(create=true)
MyStatelessComponent myComponent;

but this doesn't:
@In
MyStatelessComponent myComponent;

It was easy to figure out that it apparently is required, but from looking at the documentation this isn't clear. I also found it difficult to think about "creation of a component" when it is already there in the stateless EJB pool. I checked the code and there is some consistency in the internal logic, of course.

Users however might read the docs and say: "@In searches all contexts hierarchically, so it should find myComponent in STATELESS, because Seam logged that binding on startup." 

Also, attempts to remove the create="true" with 

@In(value = "myComponent", scope = ScopeType.STATELESS)
MyStatelessComponent myComponent;

resulted in JNDI lookup("myComponent"), which makes not much sense and returns null.

I suggest we add something to the documentation about lookup/injection of stateless components (I'm not sure if I'm 100% right about this, otherwise I would have added it).

Side note, I found the following additional debug logging lines in Component.java very helpful during development:

   private Object getInstanceToInject(In in, String name, Object bean, boolean enforceRequired)
   {
      Object result;
      if ( name.startsWith("#") )
      {
         log.debug("Searching for injection variable with value binding expression: " + name);
         FacesContext facesCtx = FacesContext.getCurrentInstance();
         Application application = facesCtx.getApplication();
         result = application.createValueBinding(name).getValue(facesCtx);
      }
      else if (in.scope()==ScopeType.UNSPECIFIED)
      {
         log.debug("Searching hierarchically for injection variable in all scopes: " + name);
         result = getInstance(name, in.create());
      }
      else
      {
         if ( in.create() )
         {
            throw new IllegalArgumentException(
                  "cannot combine create=true with explicit scope on @In: " +
                  getAttributeMessage(name)
               );
         }
         log.debug("Searching for injection variable in scope: " + name + ", scope: " + in.scope());
         result = in.scope().getContext().get(name);
      }

      if (result==null && enforceRequired && in.required())
      {
         throw new RequiredException(
               "In attribute requires value for component: " +
               getAttributeMessage(name)
            );
      }
      else
      {
         return result;
      }
   }


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:39:42 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Thu, 28 Sep 2006 14:39:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-155) loanbrokerRequestDir
 and
 loanbrokerEmailTemplatePath need to be dynamically configured with the
 loanbroker configure ant task
Message-ID: <25899341.1159468782668.JavaMail.jira@cloud.prod.atl2.jboss.com>

loanbrokerRequestDir and loanbrokerEmailTemplatePath need to be dynamically configured with the loanbroker configure ant task
-----------------------------------------------------------------------------------------------------------------------------

                 Key: JBESB-155
                 URL: http://jira.jboss.com/jira/browse/JBESB-155
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1, 4.0 Beta 1
         Environment: any
            Reporter: Kurt Stam
         Assigned To: Tom Fennelly


The following two parameters are still not part of the trailblazer config script.

    loanbrokerRequestDir="/cygwin/home/kstam/dev/loanbroker_MP1/TrailBlazer-rtfiles/BankInput"
    loanbrokerEmailTemplatePath="/cygwin/home/kstam/dev/loanbroker_MP1/template"

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:50:42 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 28 Sep 2006 14:50:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-956) "no selection"
 for Theme Leads to Null Pointer Exception
In-Reply-To: <24425396.1152887231411.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <175895.1159469442052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-956?page=all ]

Roy Russo resolved JBPORTAL-956.
--------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.4.1 Final)
       Resolution: Done
         Assignee: Roy Russo

now default to default theme in layout definition.

> "no selection" for Theme Leads to Null Pointer Exception
> --------------------------------------------------------
>
>                 Key: JBPORTAL-956
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-956
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.4 Final
>         Environment: Fedora Core 5
>            Reporter: Richard Mitchell
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> I was experimenting with theme selection in 2.4.0-CR1.  I tried each of the four defined ones which each worked great.  I then tried "no selection" to see how that behaved.  I received an HTTP 500 error with a Null Pointer Exception whenever I went to a page from that point forward.
> I hadn't really "customized" much yet so that, after suggested in the user forum, I blew away the database.  All is fine now.  I am avoiding that "no selection" entry though.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:53:42 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 28 Sep 2006 14:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-823) Access to
 Portlet Action Request in LayoutStragegy
Message-ID: <9519351.1159469622282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-823?page=all ]

Roy Russo resolved JBPORTAL-823.
--------------------------------

    Fix Version/s: 2.4.1 Final
                   2.6.Alpha1
       Resolution: Won't Fix
         Assignee: Roy Russo

> Access to Portlet Action Request in LayoutStragegy
> --------------------------------------------------
>
>                 Key: JBPORTAL-823
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-823
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.2 Final
>         Environment: Any
>            Reporter: patrickdalla
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>
> I want to maximize a portlet when the user clicks in the edit button.
> I've made this using the layoutStrategy to chage the WindowState if strategyContext.getTargetPortlet().getPortletMode() is equal Mode.EDIT.
> But, after the portlet is in edit mode, I cannot chage his WindowState.
> I would like a way to change the windowstate when the user clicks the edit button but after in edit mode he could minimize the portlet or change the window state.
> Maybe if I could access de ActionRequest in LayoutStrategy.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:56:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3454) Unable to set
 negative values for MBean attributes using Twiddle command
In-Reply-To: <19472192.1154493671368.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25392908.1159469801761.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3454?page=all ]

Sakthi Samabsivam resolved JBAS-3454.
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
       Resolution: Done

Code is completed:Setcommand and SetAttrCommand is modified to accept valid attributes. 

> Unable to set  negative  values for MBean attributes using Twiddle command
> --------------------------------------------------------------------------
>
>                 Key: JBAS-3454
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3454
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
> For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
> Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
> Possible problem might be, GetOpt class used in the org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as
> an invalid option.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 15:15:41 2006
From: jira-events at jboss.com (Andrew Rubinger (JIRA))
Date: Thu, 28 Sep 2006 15:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <20200500.1159470941844.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12344246 ] 
            
Andrew Rubinger commented on EJBTHREE-402:
------------------------------------------

Ignore above comments; wrong version patched and checked.

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 15:53:42 2006
From: jira-events at jboss.com (Travis Klotz (JIRA))
Date: Thu, 28 Sep 2006 15:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-759) Hibernate variable
 type matchers do not deal HibernateProxy objects.
Message-ID: <11128760.1159473222112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Hibernate variable type matchers do not deal HibernateProxy objects.
--------------------------------------------------------------------

                 Key: JBPM-759
                 URL: http://jira.jboss.com/jira/browse/JBPM-759
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Travis Klotz
         Assigned To: Tom Baeyens


The hibernate type matchers(HibernateLongIdMatcher, HibernateStringIdMatcher) do not match against persistant objects that are wrapped in hibernate generated proxies.  

For example, if I have a User class registered with hibernate, and I try to store a lazily instantiated User object as a context variable in jBPM, The class of the User instance is not User,  its something like  User$$EnhancedByCGLIB$$12345.  When the hibernate type matchers try to match against this class,  they do so by checking the hibernate session factory for any metadata about the argument.  But the session factory does not know anything about User$$EnhancedByCGLIB$$12345, only User, which results in a no match.

I solved this localy by extending the type matchers and explicitly checking the argument for the HibernateProxy interface.  If I found it, I ran the rest of the checks against the super class of the argument.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:14:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 16:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
Message-ID: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to set  Valid negative  values for MBean attributes using Twiddle 
-------------------------------------------------------------------------

                 Key: JBAS-3718
                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1
            Reporter: Sakthi Samabsivam
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA


When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
 For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
 Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
 Possible problem might be, GetOpt class used in the 
 org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:14:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 16:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16882637.1159474481753.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Sakthi Samabsivam reassigned JBAS-3718:
---------------------------------------

    Assignee: Sakthi Samabsivam

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:23:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 16:23:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-561) Write two
 simple examples
 (distributed queue/topic) and include them in the set shipped with the
 release
Message-ID: <27083718.1159475022538.JavaMail.jira@cloud.prod.atl2.jboss.com>

Write two simple examples (distributed queue/topic) and include them in the set shipped with the release
--------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-561
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-561
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:26:42 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Thu, 28 Sep 2006 16:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-369) @Create and
 @Begin(FlushModeType.MANUAL) execute in wrong order
Message-ID: <29538664.1159475202156.JavaMail.jira@cloud.prod.atl2.jboss.com>

@Create and @Begin(FlushModeType.MANUAL) execute in wrong order
---------------------------------------------------------------

                 Key: JBSEAM-369
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-369
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


This is CVS HEAD:

@Name("catalog")
@Stateful
public class CatalogBean implements Catalog {

    @In(value = "caveatEmptorEM", create = true)
    private EntityManager em;

    @Create
    @Begin(flushMode = FlushModeType.MANUAL)
    public void refreshRootCategories() {
    ...
}

The EntityManager is in FlushMode.AUTO because it is injected before the ConversationInterceptor runs and reads the @Begin annotation. 

So ManagedPersistenceContext.create() runs and sets the flush mode before the setFlushMode() method on the Conversation component is called.


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:29:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 16:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-562) Adjust the
 installation script to support a clustered installation
Message-ID: <2558336.1159475381657.JavaMail.jira@cloud.prod.atl2.jboss.com>

Adjust the installation script to support a clustered installation
------------------------------------------------------------------

                 Key: JBMESSAGING-562
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-562
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:29:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 16:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-563) Update the
 documentation with a Clustering Intro
Message-ID: <284336.1159475381808.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update the documentation with a Clustering Intro
------------------------------------------------

                 Key: JBMESSAGING-563
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-563
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:32:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 28 Sep 2006 16:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
Message-ID: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change structure of ClusteredSSO data in tree cache to avoid lock issues
------------------------------------------------------------------------

                 Key: JBAS-3720
                 URL: http://jira.jboss.com/jira/browse/JBAS-3720
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.CR1


For each SSO entry, their should be child node per server where the SSO has been used.  This is different from the current where all the session data for an SSO is in one node. The data map in each child node would hold the session ids of the sessions active on that server.

This kind of structure avoids most lock contention between different servers.

Can't do this in 4.0.x as it prevents interoperation with earlier releases.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:35:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 28 Sep 2006 16:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3721) Clustered SSO
 entries not properly cleaned up if a server crashes
Message-ID: <27529202.1159475741727.JavaMail.jira@cloud.prod.atl2.jboss.com>

Clustered SSO entries not properly cleaned up if a server crashes 
------------------------------------------------------------------

                 Key: JBAS-3721
                 URL: http://jira.jboss.com/jira/browse/JBAS-3721
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-4.0.6.CR1


If a server crashes, the entries for its sessions in the clustered sso cache will never be removed, and thus the sso may never be removed.

TreeCacheSSOManager needs to listen for view changes and discard sessions associated with dead servers.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:32:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 17:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17838870.1159479161540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Sakthi Samabsivam closed JBAS-3718.
-----------------------------------

    Resolution: Duplicate Issue

It was created with with wrong type of patch, instead of a support patch.

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:50:42 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:50:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
Message-ID: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>

on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
--------------------------------------------------------------

                 Key: JBAS-3722
                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.5.GA
         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
            Reporter: Prabhat Jha
         Assigned To: Scott M Stark


testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :

javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
	at javax.naming.InitialContext.lookup(InitialContext.java:347)
	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
	... 19 more
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
	... 20 more
Caused by: java.net.ConnectException: Connection refused: connect
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
	at java.net.Socket.connect(Socket.java:461)
	at java.net.Socket.connect(Socket.java:411)
	at java.net.Socket.<init>(Socket.java:310)
	at java.net.Socket.<init>(Socket.java:212)
	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:59:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
Message-ID: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>

on Windowns: org.jboss.test.jrmp.test fail with CNFE
----------------------------------------------------

                 Key: JBAS-3723
                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
            Reporter: Prabhat Jha


Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.

DynLoadingFromSARUnitTestCase
DynLoadingFromSARUnpackedUnitTestCase 
DynLoadingUnitTestCase 


javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
	at javax.naming.InitialContext.lookup(InitialContext.java:347)
	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:219)
	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
	... 18 more





-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:59:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21289590.1159480781829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Prabhat Jha updated JBAS-3723:
------------------------------

          Component/s: Remoting
    Affects Version/s: JBossAS-4.0.5.GA

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:59:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9980784.1159480781991.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Prabhat Jha reassigned JBAS-3723:
---------------------------------

    Assignee: Scott M Stark

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:03:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 18:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1060) Empty
 preferences values are not retrieved properly
Message-ID: <10898953.1159481021650.JavaMail.jira@cloud.prod.atl2.jboss.com>

Empty preferences values are not retrieved properly
---------------------------------------------------

                 Key: JBPORTAL-1060
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1060
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:32:41 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 28 Sep 2006 18:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21786345.1159482761693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Ryan Campbell updated JBAS-3723:
--------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:32:41 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 28 Sep 2006 18:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22504470.1159482761902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3722?page=all ]

Ryan Campbell updated JBAS-3722:
--------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:50:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 18:50:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1060) Empty
 preferences values are not retrieved properly
In-Reply-To: <10898953.1159481021650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5405081.1159483841691.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1060?page=all ]

Julien Viet resolved JBPORTAL-1060.
-----------------------------------

    Resolution: Done

> Empty preferences values are not retrieved properly
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1060
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1060
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:56:41 2006
From: jira-events at jboss.com (Richard Achmatowicz (JIRA))
Date: Thu, 28 Sep 2006 18:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-554) Create an
 Admin
 abstraction that would allow running generic JMS tests regardless of
 provider implementation
In-Reply-To: <10709624.1159217701106.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28276671.1159484201465.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-554?page=comments#action_12344268 ] 
            
Richard Achmatowicz commented on JBMESSAGING-554:
-------------------------------------------------

I have had a look at the existing approach to incorporating generic (JMS provider neutral)  JMS tests into the AS testsuite. I outlined there the problems I could forsee in using the approach.  Please see the posting: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91386

I would like to try to convert one substantial test case (one which involves a lot of interaction with the server via the interface provided by JBossTestCase, in addition to any adminsitartive functions) to see how the approach works in practice. 




> Create an Admin abstraction that would allow running generic JMS tests regardless of provider implementation
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-554
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-554
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Richard Achmatowicz
>             Fix For: 1.2.0.Beta1
>
>
> Since Messaging and JBossMQ use slightly different ways of deploying their administered objects (destinations and connection factories), we need to create an unified Admin interface that would allow to deploy these artifacts regardless of provider implementation, and then create plug-ins for Messaging and MQ. 
> Initial work in this direction has been done by Adrian, see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:26:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 19:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1061) Support
 localized description of portlet preference entries
Message-ID: <29515665.1159486001527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support localized description of portlet preference entries
-----------------------------------------------------------

                 Key: JBPORTAL-1061
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1061
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:26:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 19:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1061) Support
 localized description of portlet preference entries
In-Reply-To: <29515665.1159486001527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1467200.1159486001686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1061?page=all ]

Julien Viet updated JBPORTAL-1061:
----------------------------------

    Priority: Minor  (was: Major)

> Support localized description of portlet preference entries
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1061
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1061
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:38:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 19:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
Message-ID: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>

Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
-----------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-564
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR5, 1.2.0.Alpha1
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Minor
             Fix For: 1.0.1.CR6, 1.2.0.Alpha1


Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.

Investigate.

In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:38:41 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Thu, 28 Sep 2006 19:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-154) Change
 configuration for FTP
 listeners/actions to avoid need to replicate FTP parameters
In-Reply-To: <4026448.1159447421501.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18526164.1159486721772.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-154?page=comments#action_12344271 ] 
            
Esteban Schifman commented on JBESB-154:
----------------------------------------

I have introduced a kludge to avoid replication of FTP parameters in two different places.  It's quite un-elegant:  the listener will include the parameters needed by the action class inside the message. These parameters do NOT belong in the message as they should be configuration values for the action class itself, but it is a way around having to replicate the values.

> Change configuration for FTP listeners/actions to avoid need to replicate FTP parameters
> ----------------------------------------------------------------------------------------
>
>                 Key: JBESB-154
>                 URL: http://jira.jboss.com/jira/browse/JBESB-154
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0
>            Reporter: Esteban Schifman
>         Assigned To: Esteban Schifman
>            Priority: Minor
>
> FTP server/username/password are needed both by the RemoteDirectoryPoller, and the FTP classes
> As it stands now, they need to be replicated in the xml configuration file for listeners and actions.  This is not appropriate and we should find ways to avoid this need.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:29:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 20:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1061) Support
 localized description of portlet preference entries
In-Reply-To: <29515665.1159486001527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25487229.1159489781586.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1061?page=all ]

Julien Viet resolved JBPORTAL-1061.
-----------------------------------

    Resolution: Done

> Support localized description of portlet preference entries
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1061
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1061
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:35:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-275) Move Selector
 processing IN the Channel
Message-ID: <4134343.1159490142198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-275?page=all ]

Ovidiu Feodorov updated JBMESSAGING-275:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> Move Selector processing IN the Channel
> ---------------------------------------
>
>                 Key: JBMESSAGING-275
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-275
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha2
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Currently, a consumer "arrests" a message that is being handled to it and doesn't match the Selector. That means it returns an active Delivery for it, but it doesn't forward the message to the client. This is because the consumer needs to be able to receiver further messages coming after the non-matching message, and that may potentially match the selector.
> This is a poor solution that doesn't scale. We may end up with lots of non-matching messages being "arrested" by a consumer, while they could just be simply returned to the channel and forwarded to other potential consumers.
> A possible (right) approach is to move selector processing in the Channel, so the message is not even handled to the non-accepting cosumer. Review this and refactor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:35:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-16) A
 PointToMultipoint should be able to do delivery on separate threads
Message-ID: <9473846.1159490142402.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-16?page=all ]

Ovidiu Feodorov updated JBMESSAGING-16:
---------------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> A PointToMultipoint should be able to do delivery on separate threads
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-16
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-16
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: Messaging Core
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:35:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-517) Implement
 intelligent balancer
In-Reply-To: <8674188.1155575300202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20299654.1159490142554.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-517?page=all ]

Ovidiu Feodorov closed JBMESSAGING-517.
---------------------------------------

    Resolution: Done

> Implement intelligent balancer
> ------------------------------
>
>                 Key: JBMESSAGING-517
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-517
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Implement intelligent balancer as described in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <5779613.1159490322339.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ]

Ovidiu Feodorov updated JBMESSAGING-407:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha2
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-518) Implement
 distributed destinations
In-Reply-To: <13023948.1155575300385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17427252.1159490322616.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-518?page=all ]

Ovidiu Feodorov closed JBMESSAGING-518.
---------------------------------------

    Resolution: Done

> Implement distributed destinations
> ----------------------------------
>
>                 Key: JBMESSAGING-518
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-518
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Implement distributed queue and topic as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-289) Make service
 container configurable wrt datasource and persistence manager config
Message-ID: <11944163.1159490322789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-289?page=all ]

Ovidiu Feodorov updated JBMESSAGING-289:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> Make service container configurable wrt datasource and persistence manager config
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-289
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-289
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha2
>
>
> Must be made configurable so test suite can be run against different databases with different pm configs

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-548)
 JBossConnection.finalizer()
 causes remote tests to occasionaly fail with "Cannot find generator for
 serverid:server.0"
In-Reply-To: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6114019.1159490322924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-548?page=all ]

Ovidiu Feodorov updated JBMESSAGING-548:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> JBossConnection.finalizer() causes remote tests to occasionaly fail with "Cannot find generator for serverid:server.0"
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-548
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha2
>
>
> Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:43 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 20:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-790) NPE on getNotifier
 after cache instantiation
Message-ID: <19812154.1159490323100.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE on getNotifier after cache instantiation
--------------------------------------------

                 Key: JBCACHE-790
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-790
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Manik Surtani
             Fix For: 2.0.0


Consider the following scenario:

cache = DefaultCacheFactory.createInstance(config, false); // not to start cache lifecycle
cache.getNotifier(); // return null becuase it is created in create() method call.

I think we need to move the notifier creation to the constructor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:43 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-444) Release
	1.2.0.Alpha1
In-Reply-To: <4902145.1153769531475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21444078.1159490323249.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-444?page=all ]

Ovidiu Feodorov updated JBMESSAGING-444:
----------------------------------------

    Priority: Blocker  (was: Major)

> Release 1.2.0.Alpha1
> --------------------
>
>                 Key: JBMESSAGING-444
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-444
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:14:41 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 28 Sep 2006 21:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-201) Release 1.1 beta 3
In-Reply-To: <4511003.1153758791655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30719085.1159492481651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-201?page=all ]

Alejandro Guizar resolved BPEL-201.
-----------------------------------

    Resolution: Out of Date

Beta 3 will be skipped to focus on GA.

> Release 1.1 beta 3
> ------------------
>
>                 Key: BPEL-201
>                 URL: http://jira.jboss.com/jira/browse/BPEL-201
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> The focus of this release is on fault handlers and compensation.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:17:41 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 28 Sep 2006 21:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-212) Modularize package
 org.jbpm.bpel.def
In-Reply-To: <7572.1159228681195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4591172.1159492661666.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-212?page=all ]

Alejandro Guizar resolved BPEL-212.
-----------------------------------

    Resolution: Done

> Modularize package org.jbpm.bpel.def
> ------------------------------------
>
>                 Key: BPEL-212
>                 URL: http://jira.jboss.com/jira/browse/BPEL-212
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 2
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> The package org.jbpm.bpel.def concentrates all activity definitions and has become monolithic. The proposal is breaking it as follows:
> org.jbpm.bpel.graph.def: Core concepts, including BpelDefinition, Activity, CompositeActivity and LinkDefinition.
> org.jbpm.bpel.graph.basic: Basic activities
> org.jbpm.bpel.graph.struct: Structured activities
> org.jbpm.bpel.graph.scope: Scope activity plus fault, compensation, event and termination handlers
> For consistency, org.jbpm.bpel.exe becomes org.jbpm.bpel.graph.exe. Because the number of execution objects is small, there is no need to break this package.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:26:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-370) Default @Out scope
 to the component scope
Message-ID: <13701528.1159493201633.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default @Out scope to the component scope
-----------------------------------------

                 Key: JBSEAM-370
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-370
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Currently @Out defaults to EVENT scope for simple values that are not Seam components. For consistence with @DataModel, we should change to defaulting to the scope of the component which outjects the value. This is probably a better default anyway.

Note that this is a breaking change, but best 'tis done now.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:26:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-370) Default @Out scope
 to the component scope
In-Reply-To: <13701528.1159493201633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26029816.1159493201921.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-370?page=all ]

Gavin King closed JBSEAM-370.
-----------------------------

    Resolution: Done

> Default @Out scope to the component scope
> -----------------------------------------
>
>                 Key: JBSEAM-370
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-370
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Currently @Out defaults to EVENT scope for simple values that are not Seam components. For consistence with @DataModel, we should change to defaulting to the scope of the component which outjects the value. This is probably a better default anyway.
> Note that this is a breaking change, but best 'tis done now.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:29:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-371) s:link does not
 propagate data model var
Message-ID: <14636107.1159493381980.JavaMail.jira@cloud.prod.atl2.jboss.com>

s:link does not propagate data model var
----------------------------------------

                 Key: JBSEAM-371
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-371
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: JSF
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


When using h:commandLink and h:commandButton, you can use the iterator variable in the method binding expression. s:link should be the same.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:29:42 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-371) s:link does not
 propagate data model var
In-Reply-To: <14636107.1159493381980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25125796.1159493382120.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-371?page=all ]

Gavin King updated JBSEAM-371:
------------------------------

    Description: When using h:commandLink and h:commandButton inside a h:dataTable, you can use the iterator variable in the method binding expression. s:link should be the same.  (was: When using h:commandLink and h:commandButton, you can use the iterator variable in the method binding expression. s:link should be the same.)

> s:link does not propagate data model var
> ----------------------------------------
>
>                 Key: JBSEAM-371
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-371
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> When using h:commandLink and h:commandButton inside a h:dataTable, you can use the iterator variable in the method binding expression. s:link should be the same.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:29:42 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-371) s:link does not
 propagate data model var
In-Reply-To: <14636107.1159493381980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10474901.1159493382233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-371?page=all ]

Gavin King closed JBSEAM-371.
-----------------------------

    Resolution: Done

> s:link does not propagate data model var
> ----------------------------------------
>
>                 Key: JBSEAM-371
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-371
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> When using h:commandLink and h:commandButton inside a h:dataTable, you can use the iterator variable in the method binding expression. s:link should be the same.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:32:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-324) <s:link
 action="#{...}"/> does not work with clustering or bookmarking
In-Reply-To: <1013539.1154400311354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30834671.1159493561568.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-324?page=comments#action_12344282 ] 
            
Gavin King commented on JBSEAM-324:
-----------------------------------

Ack, not so easy. There seems to be really no good way to implement this. Perhaps some solution using encryption?

> <s:link action="#{...}"/> does not work with clustering or bookmarking
> ----------------------------------------------------------------------
>
>                 Key: JBSEAM-324
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-324
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> We need to pass the id of the HtmlLink component, instead of the encoded method name.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:32:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-316) The view attribute
 functionality of s:link tag extension
In-Reply-To: <29779016.1153601891526.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15500945.1159493561998.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-316?page=all ]

Gavin King updated JBSEAM-316:
------------------------------

    Fix Version/s:     (was: 1.1)

> The view attribute functionality of s:link tag extension
> --------------------------------------------------------
>
>                 Key: JBSEAM-316
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-316
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: N/A
>            Reporter: Slawomir Trybus
>            Priority: Minor
>
> I'd like to propose extending of the <s:link .../> tag functionality in the view attribute area by adding value-binding feature.
> example:
> <s:link view="#{...}" />
> There is inevitible to create another method returning outcome string with the action attribute in the current functionality of this tag. Such a solution would provide derived url without extra method execution.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 22:20:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 22:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-791) PojoCache to
 revisit implementation for get/put Options
Message-ID: <18175183.1159496441631.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to revisit implementation for get/put Options
-------------------------------------------------------

                 Key: JBCACHE-791
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-791
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


During the initial implementation of PojoCache, we have to disable the Option API like supressLocking, etc in InternaHelper. We need to revisit them to make sure they are performant.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 22:47:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 22:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-680) TreeCache demo gui
 to update view instanteously
Message-ID: <8887952.1159498061847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-680?page=all ]

Ben Wang updated JBCACHE-680:
-----------------------------

    Fix Version/s: 2.0.0
                       (was: 1.4.0)

> TreeCache demo gui to update view instanteously
> -----------------------------------------------
>
>                 Key: JBCACHE-680
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-680
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> Previously the demo gui window has the onModify view change disabled becuase the potential deadlock when there is a tx scope and the Swing GUI view update is coming in from a different thread context. I can't reproduce this on 1.4 release now but to safeguard it, on the GUI side, I have used the getData() api to bypass the locking anyway.
> Now, when I run the gui on PojoCache tutorial, it will have the field update automatically.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 22:47:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 22:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-680) TreeCache demo gui
 to update view instanteously
Message-ID: <21115871.1159498061950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-680?page=all ]

Ben Wang updated JBCACHE-680:
-----------------------------

    Fix Version/s: 1.4.0.SP2

> TreeCache demo gui to update view instanteously
> -----------------------------------------------
>
>                 Key: JBCACHE-680
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-680
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> Previously the demo gui window has the onModify view change disabled becuase the potential deadlock when there is a tx scope and the Swing GUI view update is coming in from a different thread context. I can't reproduce this on 1.4 release now but to safeguard it, on the GUI side, I have used the getData() api to bypass the locking anyway.
> Now, when I run the gui on PojoCache tutorial, it will have the field update automatically.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 01:27:42 2006
From: jira-events at jboss.com (Grant Quimby (JIRA))
Date: Fri, 29 Sep 2006 01:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3724)
 NotFoundInDispatcherException
 from InvokerLocator when accessing remote calls when on a non default port
Message-ID: <30204193.1159507662325.JavaMail.jira@cloud.prod.atl2.jboss.com>

NotFoundInDispatcherException from InvokerLocator when accessing remote calls when on a non default port
--------------------------------------------------------------------------------------------------------

                 Key: JBAS-3724
                 URL: http://jira.jboss.com/jira/browse/JBAS-3724
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services, EJB3, Remoting
    Affects Versions: JBossAS-4.0.4.GA
         Environment: One JBoss 4.0.4.GA install with two instances, one on the default ports and one on ports with an increase of 1000 on all port numbers. 
            Reporter: Grant Quimby
         Assigned To: Dimitris Andreadis
            Priority: Blocker


When trying to access a remote application that is running in a server instance that does not have the default InvokerLocator port (3873) the remote caller recieves a NotFoundInDispatcherException when trying to call a method in the EJB3 Stateless Session Bean as the EJB3 Session Bean's InvokerLocator is at port 4873 and not port 3873 where the Remote Proxy looks. 

Similar issue for Service Beans at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89537

This is okay presently but in approximately two weeks we need to be running four instances with Session beans in two of them, which is currently not possible in a production version.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 02:11:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 02:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
Message-ID: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>

Race Condition between Topic/Queue.getMessageCount and Deliver Thread
---------------------------------------------------------------------

                 Key: JBMESSAGING-565
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.2.0.Alpha1
            Reporter: Clebert Suconic
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Alpha2


This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.

QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.

PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder

deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.

While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.

To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.

I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 02:14:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 02:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-565) Race
 Condition between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11408645.1159510481548.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic reassigned JBMESSAGING-565:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha2
>
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 02:14:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 02:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30766159.1159510481679.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic updated JBMESSAGING-565:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975072#3975072

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha2
>
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:20:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <162341.1159514441476.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Dimitris Andreadis reopened JBAS-3718:
--------------------------------------

             

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:23:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16768762.1159514621712.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Dimitris Andreadis closed JBAS-3718.
------------------------------------

    Fix Version/s: No Release
                       (was: JBossAS-4.0.5.GA)
       Resolution: Done

I made a comment in the original case. The use of '--' shouldn't tell getopts to stop processing options? This needs to be invastigated.

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: No Release
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:23:42 2006
From: jira-events at jboss.com (raehalme (JIRA))
Date: Fri, 29 Sep 2006 03:23:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3725) Specify DataSource
 settings at the application level (in the .EAR)
Message-ID: <18292068.1159514622075.JavaMail.jira@cloud.prod.atl2.jboss.com>

Specify DataSource settings at the application level (in the .EAR)
------------------------------------------------------------------

                 Key: JBAS-3725
                 URL: http://jira.jboss.com/jira/browse/JBAS-3725
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: raehalme
         Assigned To: Alexey Loubyansky


At the moment you can specify application's DataSource settings either in the global JBoss configuration (standardjbosscmp-jdbc.xml) or in the EJB JAR (META-INF/jbosscmp-jdbc.xml). When developing EJB components that are re-used in many applications, it is frustrating to have to create a separate EJB JAR version for each application in order to be able to specify which DataSource to use for the EJB component. It would be much easier if the DataSource could be specified at the application level (in the EAR) because often all the application's EJB components use the same DataSource. In addition because the EJB JAR would no longer contain deployment specific settings, you could include the same EJB JAR file in all the application's EAR files.

I propose that this improvement is implemented by reading default settings also from the EAR's META-INF/jbosscmp-jdbc.xml. You could then specify a default configuration for each application and still override it inside the EJB JAR if necessary. I have implemented this functionality using the source code from version 4.0.4.GA. I will attach the necessary patches to this issue for your evaluation.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:26:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6547409.1159514801679.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3723?page=comments#action_12344312 ] 
            
Dimitris Andreadis commented on JBAS-3723:
------------------------------------------

Since when we are testing on windows? And is this the result of a full test run?

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:26:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3717) correct TCL should
 be used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9974285.1159514801824.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3717?page=all ]

Dimitris Andreadis updated JBAS-3717:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:29:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 03:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-193) Enable
 configurable timeout on all calls of RpcServerCall.remoteInvoke(...)
Message-ID: <24252972.1159514981664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-193?page=all ]

Ovidiu Feodorov closed JBMESSAGING-193.
---------------------------------------

    Resolution: Out of Date

Refers to old code.

> Enable configurable timeout on all calls of RpcServerCall.remoteInvoke(...)
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-193
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-193
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR3
>            Reporter: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>
> Client code currently lacks the possibility of administratively specify a timeout on RpcServerCall.remoteInvoke(...) calls.  This is case for PeerSupport, QueuePeer and maybe others. Add the possibility to specify this timeout in a configuration file.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:33:41 2006
From: jira-events at jboss.com (raehalme (JIRA))
Date: Fri, 29 Sep 2006 03:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3725) Specify DataSource
 settings at the application level (in the .EAR)
In-Reply-To: <18292068.1159514622075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8308686.1159515221702.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3725?page=all ]

raehalme updated JBAS-3725:
---------------------------

    Attachment: JDBCEntityMetaData.java.patch
                JDBCXmlFileLoader.java.patch

JDBCXmlFileLoader.java: After reading standardjbosscmp-jdbc.xml the load method now reads META-INF/jbosscmp-jdbc.xml from the EAR, if available.

JDBCEntityMetaData.java: datasourceMappingName is now copied from the defaultValues. This change is necessary to support multiple levels of default values (the application's and the system's).

> Specify DataSource settings at the application level (in the .EAR)
> ------------------------------------------------------------------
>
>                 Key: JBAS-3725
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3725
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: raehalme
>         Assigned To: Alexey Loubyansky
>         Attachments: JDBCEntityMetaData.java.patch, JDBCXmlFileLoader.java.patch
>
>
> At the moment you can specify application's DataSource settings either in the global JBoss configuration (standardjbosscmp-jdbc.xml) or in the EJB JAR (META-INF/jbosscmp-jdbc.xml). When developing EJB components that are re-used in many applications, it is frustrating to have to create a separate EJB JAR version for each application in order to be able to specify which DataSource to use for the EJB component. It would be much easier if the DataSource could be specified at the application level (in the EAR) because often all the application's EJB components use the same DataSource. In addition because the EJB JAR would no longer contain deployment specific settings, you could include the same EJB JAR file in all the application's EAR files.
> I propose that this improvement is implemented by reading default settings also from the EAR's META-INF/jbosscmp-jdbc.xml. You could then specify a default configuration for each application and still override it inside the EJB JAR if necessary. I have implemented this functionality using the source code from version 4.0.4.GA. I will attach the necessary patches to this issue for your evaluation.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:53:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 29 Sep 2006 03:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3717) correct TCL should
 be used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29100087.1159516421617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3717?page=comments#action_12344315 ] 
            
Alexey Loubyansky commented on JBAS-3717:
-----------------------------------------

A testcase and fix committed to Branch_4_0.

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 06:32:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 06:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3726) Introduce basic
 twiddle tests in the testsuite
Message-ID: <24015765.1159525961573.JavaMail.jira@cloud.prod.atl2.jboss.com>

Introduce basic twiddle tests in the testsuite
----------------------------------------------

                 Key: JBAS-3726
                 URL: http://jira.jboss.com/jira/browse/JBAS-3726
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.6.CR1


We currently have no automated tests for twidde.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 06:32:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 06:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3726) Introduce basic
 twiddle testing in the testsuite
In-Reply-To: <24015765.1159525961573.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29879945.1159525961692.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3726?page=all ]

Dimitris Andreadis updated JBAS-3726:
-------------------------------------

    Summary: Introduce basic twiddle testing in the testsuite  (was: Introduce basic twiddle tests in the testsuite)

> Introduce basic twiddle testing in the testsuite
> ------------------------------------------------
>
>                 Key: JBAS-3726
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3726
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We currently have no automated tests for twidde.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:11:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:11:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18368366.1159528302039.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis closed JBAS-3723.
------------------------------------

    Resolution: Done

They work for me using a special target 'tests-client-unit'

X:\cvs\jboss-public\jboss-4.0\testsuite>build tests-client-unit
Calling ..\tools\bin\ant.bat tests-client-unit
Buildfile: build.xml

tests-client-unit:
    [junit] Running org.jboss.test.jrmp.test.DynLoadingFromSARUnitTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.451 sec
    [junit] Running org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCa
se
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.995 sec
    [junit] Running org.jboss.test.jrmp.test.DynLoadingUnitTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 17.304 sec

BUILD SUCCESSFUL
Total time: 52 seconds

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:11:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:11:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9029404.1159528302242.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis reopened JBAS-3723:
--------------------------------------

      Assignee: Dimitris Andreadis  (was: Scott M Stark)
             

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: No Release
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:11:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:11:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25792394.1159528302463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis updated JBAS-3723:
-------------------------------------

          Component/s: Test Suite
                           (was: Remoting)
        Fix Version/s: No Release
                           (was: JBossAS-4.0.5.GA)
    Affects Version/s:     (was: JBossAS-4.0.5.GA)

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: No Release
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:14:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21378927.1159528481619.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis closed JBAS-3723.
------------------------------------

    Fix Version/s:     (was: No Release)
       Resolution: Rejected

As a note, when you open issues don't open them again the version to be released (e.g. 4.0.5.GA), since this version is not released yet!

Just leave the affects version empty.

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:23:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 07:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-138) Make TS changes
 available for AS 4.0.4 patch process
Message-ID: <29572011.1159529021616.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make TS changes available for AS 4.0.4 patch process
----------------------------------------------------

                 Key: JBTM-138
                 URL: http://jira.jboss.com/jira/browse/JBTM-138
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kevin Conner
         Assigned To: Kevin Conner


We need to provide our patches as part of the cumulative patch process for AS 4.0.4.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:26:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 07:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
Message-ID: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>

The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBTM-139
                 URL: http://jira.jboss.com/jira/browse/JBTM-139
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:26:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 07:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-140) The JTS
 UserTransaction raises the
 wrong exception if the transaction has been terminated through the
 transaction reaper as a consequence of a timeout.
Message-ID: <15892972.1159529201835.JavaMail.jira@cloud.prod.atl2.jboss.com>

The JTS UserTransaction raises the wrong exception if the transaction has been terminated through the transaction reaper as a consequence of a timeout.
-------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBTM-140
                 URL: http://jira.jboss.com/jira/browse/JBTM-140
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:29:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26287616.1159529381706.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3715?page=all ]

Dimitris Andreadis closed JBAS-3715.
------------------------------------

    Resolution: Done

I think it's passing now.

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:53:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13550007.1159530821813.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344321 ] 
            
Dimitris Andreadis commented on JBAS-3722:
------------------------------------------

It could be we are not running the tests properly. Are there any environment settings needed like 

MYTESTIP_1
MYTESTIP_2

?

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 09:17:41 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 29 Sep 2006 09:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-564)
 Session.unsubscribe() leaves
 an active associated consumer (durable subscriber) in an undefined state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30076363.1159535861803.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Tim Fox closed JBMESSAGING-564.
-------------------------------

    Resolution: Rejected
      Assignee: Tim Fox  (was: Ovidiu Feodorov)

This test is not valid.

It is illegal (see JMS1.1 spec 6.11) to unsubscribe if the subscription has active consumers.

We weren't checking this in the code before.

I have now added such a check, and a test.

This test should be removed and this bug closed.

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.CR6, 1.2.0.Alpha1
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-140) The JTS
 UserTransaction raises
 the wrong exception if the transaction has been terminated through the
 transaction reaper as a consequence of a timeout.
In-Reply-To: <15892972.1159529201835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33469868.1159538561886.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-140?page=all ]

Kevin Conner resolved JBTM-140.
-------------------------------

    Resolution: Rejected

> The JTS UserTransaction raises the wrong exception if the transaction has been terminated through the transaction reaper as a consequence of a timeout.
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-140
>                 URL: http://jira.jboss.com/jira/browse/JBTM-140
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-140) The JTS
 UserTransaction raises
 the wrong exception if the transaction has been terminated through the
 transaction reaper as a consequence of a timeout.
In-Reply-To: <15892972.1159529201835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26897621.1159538561732.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-140?page=comments#action_12344326 ] 
            
Kevin Conner commented on JBTM-140:
-----------------------------------

This report is incorrect, the JTS does raise an InvalidStateException when the transaction has been terminated by the transaction reaper

> The JTS UserTransaction raises the wrong exception if the transaction has been terminated through the transaction reaper as a consequence of a timeout.
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-140
>                 URL: http://jira.jboss.com/jira/browse/JBTM-140
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:11:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
In-Reply-To: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <624575.1159539101562.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-139?page=comments#action_12344327 ] 
            
Kevin Conner commented on JBTM-139:
-----------------------------------

Fixed in revision 6468

> The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-139
>                 URL: http://jira.jboss.com/jira/browse/JBTM-139
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:11:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
In-Reply-To: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21621896.1159539101733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-139?page=all ]

Kevin Conner resolved JBTM-139.
-------------------------------

    Resolution: Done

> The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-139
>                 URL: http://jira.jboss.com/jira/browse/JBTM-139
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:11:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
In-Reply-To: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10630264.1159539101852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-139?page=all ]

Kevin Conner closed JBTM-139.
-----------------------------


> The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-139
>                 URL: http://jira.jboss.com/jira/browse/JBTM-139
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:14:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-141) The fix for JBTM-139
 requires updates to the documentation.
Message-ID: <10248828.1159539281807.JavaMail.jira@cloud.prod.atl2.jboss.com>

The fix for JBTM-139 requires updates to the documentation.
-----------------------------------------------------------

                 Key: JBTM-141
                 URL: http://jira.jboss.com/jira/browse/JBTM-141
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Mark Little
             Fix For: 4.2.2


Documentation update for JBTM-139


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:35:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 10:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
Message-ID: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE on context classloader changing in EJB container when caller doesn't have a context classloader
---------------------------------------------------------------------------------------------------

                 Key: JBAS-3727
                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


The following code in org.jboss.ejb.Container
doesn't work if the caller doesn't have a context classloader,
e.g. it is using the bootstrap classloader as its classloader on the Sun JDK

      ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
      long start = System.currentTimeMillis();
      Method m = null;

      boolean setCl = false;
      Object type = null;
      String contextID = getJaccContextID();
      try
      {
         if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
         {
            setCl = true;
            SecurityActions.setContextClassLoader(this.classLoader);
         }

The classloaders should be reversed, since the ejb classloader can never be null.

Is there a reason for this optimization? I'd imagine the comparison of classloaders
is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:35:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 10:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3728) Check ClassLoader
	comparisons
Message-ID: <3800956.1159540541820.JavaMail.jira@cloud.prod.atl2.jboss.com>

Check ClassLoader comparisons
-----------------------------

                 Key: JBAS-3728
                 URL: http://jira.jboss.com/jira/browse/JBAS-3728
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Scott M Stark


The codebase needs checking for other classloader comparisons similar to that found
on the parent issue for the EJBContainer.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:50:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 29 Sep 2006 10:50:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3701)
 SystemPropertiesService does not
 properly generate server path on windows
In-Reply-To: <32333943.1159287401584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23397552.1159541441632.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3701?page=all ]

Anil Saldhana resolved JBAS-3701.
---------------------------------

    Resolution: Rejected

As per Adrian's suggestion, need to replace "/" with "${/}" for files/directories

 <!--  system properties -->
  <mbean code="org.jboss.varia.property.SystemPropertiesService"
    name="jboss:type=Service,name=SystemProperties">
    <attribute name="Properties" replace="false"> 
         log.file.location=${jboss.server.home.dir}${/}log 
         javax.net.ssl.keyStore=${jboss.server.home.dir}${/}conf${/}keystores${/}clientcert.jks 
    </attribute>
  </mbean>


This works.

> SystemPropertiesService does not properly generate server path on windows
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3701
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3701
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
>   <mbean code="org.jboss.varia.property.SystemPropertiesService"
>     name="jboss:type=Service,name=SystemProperties">
>     <attribute name="Properties" replace="false"> 
>          log.file.location=${jboss.server.home.dir}/log 
>     </attribute>
>   </mbean>
> The jboss.server.home.dir is not string replaced properly on windows.
> I suspect it to be related to the Property class in the Jboss common module.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:29:41 2006
From: jira-events at jboss.com (Darren Hartford (JIRA))
Date: Fri, 29 Sep 2006 11:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCOMMON-6) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10316736.1159543781539.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCOMMON-6?page=comments#action_12344332 ] 
            
Darren Hartford commented on JBCOMMON-6:
----------------------------------------

Adding support for the Eclipse 'bundleresource' URL would also be a huge benefit.


> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: JBCOMMON-6
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-6
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:32:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 11:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8936795.1159543961643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic updated JBMESSAGING-565:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.0.Alpha2)

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:35:41 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Fri, 29 Sep 2006 11:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-372) s:link doesn't get
 parent conversation Id after exit of nested conversation
Message-ID: <32073994.1159544141645.JavaMail.jira@cloud.prod.atl2.jboss.com>

s:link doesn't get parent conversation Id after exit of nested conversation
---------------------------------------------------------------------------

                 Key: JBSEAM-372
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-372
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


Consider this sequence:

- Conversation A -> s:link = startB(value, conversationId=A)
- Nested B ->  h:commandButton = Conversation.instance().endAndRedirect(conversationId=B);
- Conversation A -> s:link = startB(value, conversationId=null)
- crash

Basically, it looks like s:link doesn't append a conversation id if the conversation is marked as being discarded after RENDER RESPONSE. This is the case in the RENDER_RESPONSE after the redirect out of Nested B, the conversation B will be discarded. So s:link renders  without a conversation identifier. It should use the parent conversations identifier.


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:38:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12771899.1159544321729.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic closed JBMESSAGING-565.
---------------------------------------

    Resolution: Done

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>          Time Spent: 1 day, 1 hour
>  Remaining Estimate: 0 minutes
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:41:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 11:41:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-6) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31414866.1159544501865.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-6?page=all ]

Adrian Brock updated JBCOMMON-6:
--------------------------------

     Original Estimate:     (was: 4 hours)
    Remaining Estimate:     (was: 4 hours)
              Priority: Major  (was: Critical)

"FOR COMMITTERS USE ONLY" means exactly that.

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: JBCOMMON-6
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-6
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:41:42 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 11:41:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (EJBTHREE-719) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29775946.1159544502079.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-719?page=all ]

Adrian Brock moved JBCOMMON-6 to EJBTHREE-719:
----------------------------------------------

        Project: EJB 3.0  (was: JBoss Common)
            Key: EJBTHREE-719  (was: JBCOMMON-6)
    Component/s:     (was: core)

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: EJBTHREE-719
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-719
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:44:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 29 Sep 2006 11:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27290804.1159544681832.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344335 ] 
            
Brian Stansberry commented on JBAS-3722:
----------------------------------------

What IP was the server bound to?  Has to be 10.16.56.139.  That comes from the "node0=xxx" line in testsuite/local.properties.  The 10.16.56.139 in the posted stack trace comes from system property jbosstest.server.host, which by default also comes from "node0=xxx"  in local.properties.  Only way  I could see those being out of sync is if jbosstest.server.host were being overridden in some way.

The stack trace above doesn't show much, as what's being reported is the expected failure of connecting to the naming server via java.naming.provider.url.  The real test failure is why automatic discovery didn't find the server when the above exception was caught. If you could attach the junit report for this test from testsuite/output/reports that may provide more info.

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:44:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 11:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-719) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19223505.1159544681997.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-719?page=comments#action_12344336 ] 
            
Adrian Brock commented on EJBTHREE-719:
---------------------------------------

Moved the EJB3 project since I don't see what this archive browsing offers over its
more feature complete precursor org.jboss.net.URLLister[Factory]?

This should in any case be replaced with the VFS.

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: EJBTHREE-719
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-719
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:59:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 29 Sep 2006 11:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3717) correct TCL should
 be used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1133983.1159545581644.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3717?page=all ]

Alexey Loubyansky updated JBAS-3717:
------------------------------------

    Affects Version/s: JBossAS-3.2.8.SP1

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:59:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 29 Sep 2006 11:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3717) correct TCL should be
 used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19435653.1159545581859.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3717?page=all ]

Alexey Loubyansky closed JBAS-3717.
-----------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2
       Resolution: Done

Fixed.

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA, JBossAS-3.2.8.SP2
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:02:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 29 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3701)
 SystemPropertiesService does not
 properly generate server path on windows
In-Reply-To: <32333943.1159287401584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33190898.1159545761725.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3701?page=all ]

Anil Saldhana reopened JBAS-3701:
---------------------------------

             
The real issue is that the string replaced "jboss.server.home.dir" (eg: c:\something\something) goes through the call [string.getBytes("iso-8888-xxx")]  is stripped off the slashes and the end result is:

Csomethingsomething/log


> SystemPropertiesService does not properly generate server path on windows
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3701
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3701
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
>   <mbean code="org.jboss.varia.property.SystemPropertiesService"
>     name="jboss:type=Service,name=SystemProperties">
>     <attribute name="Properties" replace="false"> 
>          log.file.location=${jboss.server.home.dir}/log 
>     </attribute>
>   </mbean>
> The jboss.server.home.dir is not string replaced properly on windows.
> I suspect it to be related to the Property class in the Jboss common module.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:32:41 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Fri, 29 Sep 2006 12:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-744) Expand
 CacheLoader API to support streaming state transfer
In-Reply-To: <2386926.1156183900538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1738929.1159547561681.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-744?page=all ]

Vladimir Blagojevic resolved JBCACHE-744.
-----------------------------------------

    Resolution: Done

Resolved by introducing described methods in CacheLoader API. Default implementations of these methods have been moved to AbstractCacheLoader thus liberating concrete Cacheloader implementations from the details of partial and complete state transfer between cacheloaders. By resolving this issue cacheloader compatibility is also achieved. For example, cache node A can have FileCacheLoader and node B can have JDBCCacheLoader which are able to transfer state between them. Both streaming and byte based transfer are supported transparently from cacheloaders.



> Expand CacheLoader API to support streaming state transfer
> ----------------------------------------------------------
>
>                 Key: JBCACHE-744
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-744
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0, 1.3.0, 1.2
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0
>
>
> CacheLoader API prior to 2.0 does not support streaming state transfer feature implemented in Jgroups 2.4. In order to transfer application state to a receiving cache node we currently have to load entire state into memory and send it to a receiving cache node. Major limitation of this approach is that the state transfer that is very large (>total memory allocated by JVM) would result in OutOfMemoryException. 
> For example, if a cacheloader is pointing to a huge DOM tree, whose aggregate size is 2GB (and which has partly been passivated to disk), then the state provider cacheloader node can simply iterate over the DOM tree (activating the parts which have been passivated out to disk), and write it to the OutputStream as it traverses the tree. The receiving cacheloader will simply read from the InputStream and reconstruct the tree on its side, possibly again passivating parts to disk. Rather than having to provide a 2GB byte[] buffer (besides the state, so the needed memory is ca 4GB temporarily), streaming state transfer transfers the state in chunks of N bytes (user configurable).
> In order to accomodate this feature CacheLoader API will be expanded to include the following methods:
> void storeEntireState(InputStream s);
> void storeState(Fqn subtree,InputStream s); 
> void loadEntireState(OutputStream s);
> void loadState(Fqn subtree,OutputStream s);

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:35:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Fri, 29 Sep 2006 12:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28781081.1159547741563.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344341 ] 
            
Prabhat Jha commented on JBAS-3722:
-----------------------------------

I have just started a fresh test run on windows. I will attach the junit report once it's done which will be after 4 hours.

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:44:41 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Fri, 29 Sep 2006 12:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-332) Support concurrent
	flushing
Message-ID: <25140947.1159548281781.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support concurrent flushing
---------------------------

                 Key: JGRP-332
                 URL: http://jira.jboss.com/jira/browse/JGRP-332
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.5


JGroups 2.4 introduces FLUSH protocol that enables stop-the-world model for JGroups nodes. However, FLUSH protocol currently does not support coordination between nodes when it comes to concurrent requests for flush. For example, in JGroups 2.4 if more than one MuxChannel sitting on top of JChannel requests flush the behaviour is nondeterministic. Also, we should investigate how to combine concurrent flush requests coming from state transfer protocol with flush requests coming from GMS protocol. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 13:14:41 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Fri, 29 Sep 2006 13:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-156) consistent packaging
Message-ID: <9315890.1159550081789.JavaMail.jira@cloud.prod.atl2.jboss.com>

consistent packaging
--------------------

                 Key: JBESB-156
                 URL: http://jira.jboss.com/jira/browse/JBESB-156
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kurt Stam
         Assigned To: Mark Little


Can we do some more refactoring of package names?

For example I'd like to see everything in

'product/core/common' directory to be rooted in the org.jboss.soa.esb.common.* package.
'product/core/services' directory to be rooted in the org.jboss.soa.esb.services.* package.

Somehow it's all mixed up right now and I keep on having to click around to find classes.


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 14:02:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Fri, 29 Sep 2006 14:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30208381.1159552961995.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344342 ] 
            
Prabhat Jha commented on JBAS-3722:
-----------------------------------

This test passed when I ran with one-test. Either I messed up ip address or udpGroup while running test yesterday or someting got fixed today. We will see if this happens again during the entire test run in windows.

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 14:29:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 29 Sep 2006 14:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-650)
	SharedStoreCacheLoader
Message-ID: <30043674.1159554581764.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-650?page=all ]

Galder Zamarreno resolved JBCACHE-650.
--------------------------------------

    Resolution: Done

[JBCACHE-650] - SharedStoreCacheLoader refactored to SingletonStoreCacheLoader 
adding the ability to push the in-memory state to the underlying cache loader when 
assuming the coordinator role. Created AbstractDelegatingCacheLoader class that 
contains the basic delegating functionality. SingletonStoreCacheLoader and 
AsyncCacheLoader now extend this class. Necessary configuration options added 
and documentation has been updated to include explanation. Two singleton cache 
sample configurations added too.

> SharedStoreCacheLoader
> ----------------------
>
>                 Key: JBCACHE-650
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-650
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2
>            Reporter: Bela Ban
>         Assigned To: Galder Zamarreno
>             Fix For: 2.0.0
>
>   Original Estimate: 3 days
>          Time Spent: 4 days
>  Remaining Estimate: 0 minutes
>
> Reactive this loader, which stores modifications only if it is the current coordinator.  In addition, it should (configurable via a flag) dump the entire in-memory contents into the file system, overwriting whatever is there, when it becomes coordinator. This is only possible though if no eviction has been defined

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 14:32:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 29 Sep 2006 14:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-644) FileCacheLoader
 fails if FQN contains illegal/too many characters
Message-ID: <21814320.1159554761720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-644?page=all ]

Galder Zamarreno updated JBCACHE-644:
-------------------------------------

    Priority: Major  (was: Minor)

changed priority in order for it to appear at the top of my tasks

> FileCacheLoader fails if FQN contains illegal/too many characters
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-644
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-644
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2
>         Environment: Windows XP
>            Reporter: Amit Kasher
>         Assigned To: Galder Zamarreno
>             Fix For: 2.0.0
>
>
> When putting FQNs that are too long to become filenames, or that contain illlegal characters for filenames (semicolon, for example), the FileCacheLoader throws an IOException.
> The FileCacheLoader should encode the FQN string so that it is a valid filename.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:38:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15723842.1159558721696.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=comments#action_12344349 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-564:
---------------------------------------------

Right. This is what I meant by "investigate".

The pre-bug report code didn't do any check and it was allowing unsubscribing a durable subscription with active consumers.


> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR6
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:41:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:41:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7716808.1159558902378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-525:
-----------------------------------------

             

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:41:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:41:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16175225.1159558902715.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov updated JBMESSAGING-525:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)
                       (was: 1.2.0.Beta1)

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:41:43 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:41:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10879497.1159558903065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov closed JBMESSAGING-525.
---------------------------------------

    Resolution: Done

shited up to Alpha1

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 17:42:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Fri, 29 Sep 2006 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3729) Add alternate run-as
 mappings for container callbacks
Message-ID: <19261563.1159566161609.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add alternate run-as mappings for container callbacks
-----------------------------------------------------

                 Key: JBAS-3729
                 URL: http://jira.jboss.com/jira/browse/JBAS-3729
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: EJB2, EJB3, Security, Web (Tomcat) service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.6.CR1


Other app servers support anlternate run-as semantics from the container init/destroy lifecycle callbacks. Weblogic for example:
http://e-docs.bea.com/wls/docs81/webapp/weblogic_xml.html#1041058

This is an equivalent of <run-as> for init method for servlets. For example:
      <init-as>
        <servlet-name>FooServlet</servlet-name>
        <principal-name>joe</principal-name>
      </init-as>

   <destroy-as>
    <servlet-name>BarServlet</servlet-name>
    <principal-name>bob</principal-name>
  </destroy-as>

This would allow more control over how these methods interact with secured resources. Similar options could be added for ejb lifecycle methods as well.


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 18:11:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-28) Context Listeners
Message-ID: <32129385.1159567901511.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=all ]

Gavin King updated JBSEAM-28:
-----------------------------

    Fix Version/s: 1.1
         Priority: Major  (was: Minor)

I have implemented the following events:


org.jboss.seam.preSetVariable.<name>
org.jboss.seam.postSetVariable.<name>
org.jboss.seam.preRemoveVariable.<name>
org.jboss.seam.postRemoveVariable.<name>

org.jboss.seam.preDestroyContext.<SCOPE>
org.jboss.seam.postDestroyContext.<SCOPE>

org.jboss.seam.beginConversation
org.jboss.seam.endConversation

org.jboss.seam.beginPageflow.<name>

org.jboss.seam.createProcess.<name>
org.jboss.seam.initProcess.<name>

org.jboss.seam.initTask.<name>
org.jboss.seam.startTask.<name>
org.jboss.seam.endTask.<name>

org.jboss.seam.postConstruct.<name>
org.jboss.seam.preDestroy.<name>
org.jboss.seam.prePassivate.<name>
org.jboss.seam.postActivate.<name>

Still need to do:

org.jboss.seam.preCreateContext.<SCOPE>
org.jboss.seam.postCreateContext.<SCOPE>


> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:14:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-28) Context Listeners
Message-ID: <10378144.1159568081615.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=comments#action_12344354 ] 
            
Gavin King commented on JBSEAM-28:
----------------------------------

Or should it be postCreate/preDestroy instead of / in addition to the EJB events?

> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:53:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-28) Context Listeners
Message-ID: <30441782.1159570421726.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=all ]

Gavin King closed JBSEAM-28.
----------------------------

    Resolution: Done

> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:53:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-28) Context Listeners
Message-ID: <20441322.1159570421604.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=comments#action_12344355 ] 
            
Gavin King commented on JBSEAM-28:
----------------------------------

done and committed except for the create context events

> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:53:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-373) create context
	events
Message-ID: <29461495.1159570421851.JavaMail.jira@cloud.prod.atl2.jboss.com>

create context events
---------------------

                 Key: JBSEAM-373
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-373
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


We have events for context destruction, we also need them for creation of contexts.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 19:11:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 19:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-374) Normalize the event
	model
Message-ID: <4193874.1159571501566.JavaMail.jira@cloud.prod.atl2.jboss.com>

Normalize the event model
-------------------------

                 Key: JBSEAM-374
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-374
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Currently some events can be handled by either an @Observer method, or a method binding in events.xml. Ideally we would like this to be true for ALL events, but for now our integration with JSF and jBPM is not quite that deep. Nevertheless, there are some things we could do to allow a more consistent model where everything can be handled by either a method binding or an annotated method:


(1) Rebuild the page actions functionality on top of the Seam event bus - defining standard org.jboss.seam.page.<viewId> events that can be handled via @Observer("org.jboss.seam.page./myViewId.xhtml")

(2) Introduce "outcome observers" for JSF: if I have <h:commandButton action="myOutcome"/>, allow us to handle it using @Observer("org.jboss.seam.outcome.myOutcome")

(3) Ditto for jBPM: if I have <transition name="myTransition" ... />, allow us to handle it using @Observer("org.jboss.seam.transition.myTransition")

(4) Finally, introduce annotations layered over @Observer: @RenderPage("/myViewId.xhtml"), @Outcome("myOutcome"), @Transition("myTransition")



-- 
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

        


From jira-events at jboss.com  Fri Sep 29 19:53:41 2006
From: jira-events at jboss.com (jarkko Lietolahti (JIRA))
Date: Fri, 29 Sep 2006 19:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3730) Use caching,
 serialization and snapshots to speedup JBoss AS startup
Message-ID: <5590539.1159574021694.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use caching, serialization and snapshots to speedup JBoss AS startup
--------------------------------------------------------------------

                 Key: JBAS-3730
                 URL: http://jira.jboss.com/jira/browse/JBAS-3730
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: jarkko Lietolahti


When using JBoss AS in development i feel that the startup time of AS is waaayyy too long, it's something between 20 seconds (very trimmed down version, almost ripped off of all the required services) to 1 minute on my 2GHz laptop with 2 gigabytes of memory. 

So speed up the startup time of standard(aka default with ejb3) JBoss AS. By this i mean speed up the startups especially in development environments. It's ok for the initial startup after clean installation to take more time. But during "clean" startup JBoss AS should use caching, serialization, snapshots and all the available ways to make the next startup lightning fast. By lightning fast i mean 2 to 5 seconds.

This can ofcourse happen if nothing has changed in the configuration, which is usually the case during development where the AS has been shutdown for reasons like unrecorable error (like hanging transactions), severe hot code replace error (after which the as environment becomes too unstable to continue function correctly), or some configuration change which cannot be done while the as is "online".

>From boot.log and system.log i can see that there are places where JBoss AS could "cache"/serialize/etc stuff and on next startup use the information from the "cache". I've been trying to do a graph of JBoss AS startup based on the logs to see where the startup process spends it moments.

Maybe it would be possible to "cache" RepositoryClassLoader contents and avoid the cost of scanning default/lib directory for jar libaries which stay unchanged for most of the start-stop cycle (atleast during certain development phases).
 
I also noticed on a dual core machine some of the activity during startup/deployment doesn't scale very well. At these phases total cpu usage is ~48-52 %, which indicates that the activity doesn't get the additional benefit of multi core / cpu environment.

Of course, a mechanism to detect a change in the configuration/etc should be build also which would detect a change in configuration and reload the changed information.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 19:56:41 2006
From: jira-events at jboss.com (jarkko Lietolahti (JIRA))
Date: Fri, 29 Sep 2006 19:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3730) Use caching,
 serialization and snapshots to speedup JBoss AS startup
In-Reply-To: <5590539.1159574021694.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16802755.1159574201656.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3730?page=comments#action_12344356 ] 
            
jarkko Lietolahti commented on JBAS-3730:
-----------------------------------------

Caching of default/lib RepositoryClassLoader is just an example. 

> Use caching, serialization and snapshots to speedup JBoss AS startup
> --------------------------------------------------------------------
>
>                 Key: JBAS-3730
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3730
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: jarkko Lietolahti
>
> When using JBoss AS in development i feel that the startup time of AS is waaayyy too long, it's something between 20 seconds (very trimmed down version, almost ripped off of all the required services) to 1 minute on my 2GHz laptop with 2 gigabytes of memory. 
> So speed up the startup time of standard(aka default with ejb3) JBoss AS. By this i mean speed up the startups especially in development environments. It's ok for the initial startup after clean installation to take more time. But during "clean" startup JBoss AS should use caching, serialization, snapshots and all the available ways to make the next startup lightning fast. By lightning fast i mean 2 to 5 seconds.
> This can ofcourse happen if nothing has changed in the configuration, which is usually the case during development where the AS has been shutdown for reasons like unrecorable error (like hanging transactions), severe hot code replace error (after which the as environment becomes too unstable to continue function correctly), or some configuration change which cannot be done while the as is "online".
> From boot.log and system.log i can see that there are places where JBoss AS could "cache"/serialize/etc stuff and on next startup use the information from the "cache". I've been trying to do a graph of JBoss AS startup based on the logs to see where the startup process spends it moments.
> Maybe it would be possible to "cache" RepositoryClassLoader contents and avoid the cost of scanning default/lib directory for jar libaries which stay unchanged for most of the start-stop cycle (atleast during certain development phases).
>  
> I also noticed on a dual core machine some of the activity during startup/deployment doesn't scale very well. At these phases total cpu usage is ~48-52 %, which indicates that the activity doesn't get the additional benefit of multi core / cpu environment.
> Of course, a mechanism to detect a change in the configuration/etc should be build also which would detect a change in configuration and reload the changed information.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:47:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 00:47:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3731) The default
 ServiceBindingManager's sample bindings file should override JBoss
 Messaging's Connector configuration
Message-ID: <9539431.1159591662176.JavaMail.jira@cloud.prod.atl2.jboss.com>

The default ServiceBindingManager's sample bindings file should override JBoss Messaging's Connector configuration
------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3731
                 URL: http://jira.jboss.com/jira/browse/JBAS-3731
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
            Reporter: Ovidiu Feodorov
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


The default ServiceBindingManager's sample bindings file (${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml) should contain <service-config> entries that would override JBoss Messaging's Connector configuration.

The <service-config> should be present in all <server> bindings ("ports-default", "ports-01", "ports-02", "ports-03").

Suggested <service-config> entries:

"ports-default":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4457/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4457"/>
 </service-config></server>

"ports-01":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4557/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4557"/>
 </service-config></server>


"ports-02":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4657/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4657"/>
 </service-config></server>


"ports-03":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4757/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4757"/>
 </service-config></server>








-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:53:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 00:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-438) Allow ports
 used by JBossMessaging to be mapped using ServiceBindingManager
In-Reply-To: <4635607.1153322771332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12768324.1159592022267.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-438?page=comments#action_12344359 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-438:
---------------------------------------------

The clustering installation script deals with this issue by making a local copy of sample-bindings.xml ($JBOSS_HOME/server/<config-name>/conf/binding-manager.xml) and adding the overrides there.

The problem is that overrides are too brittle: Remoting Connector doesn't support a port reconfiguration on the fly (at least not the way ServiceBindingManager does it), so I need to hard-code full InvokerLocator configurations (with host, port, serializationType, leasePeriod, etc) in binding-manager.xml.

The correct solution of the problem is to modify the Remoting Connector to allow port and host reconfigurations on the fly, in a manner compatible with ServiceBindingManager.

> Allow ports used by JBossMessaging to be mapped using ServiceBindingManager
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-438
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-438
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:56:42 2006
From: jira-events at jboss.com (Leo Liang (JIRA))
Date: Sat, 30 Sep 2006 00:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-506) Exception thrown
 when retract, reassert and retract again
Message-ID: <18021626.1159592202304.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception thrown when retract, reassert and retract again
---------------------------------------------------------

                 Key: JBRULES-506
                 URL: http://jira.jboss.com/jira/browse/JBRULES-506
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.4, 3.0.1
            Reporter: Leo Liang
         Assigned To: Mark Proctor
         Attachments: Fact.java, test.drl, TestDriver.java

In one rule retract the object and re-assert it, then retract the object again in the following activated rule. A null pointer exception will occur at this time.

java.lang.NullPointerException
	at org.drools.reteoo.TerminalNode.retractTuple(TerminalNode.java:216)
	at org.drools.reteoo.LeftInputAdapterNode.retractObject(LeftInputAdapterNode.java:207)
	at org.drools.reteoo.ObjectSource.propagateRetractObject(ObjectSource.java:141)
	at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:180)
	at org.drools.reteoo.Rete.retractObject(Rete.java:150)
	at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:207)
	at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:77)
	at org.drools.common.AbstractWorkingMemory.retractObject(AbstractWorkingMemory.java:668)
	at org.drools.base.DefaultKnowledgeHelper.retractObject(DefaultKnowledgeHelper.java:86)
	at com.ericsson.ruletest.debug.Rule_test2_0.consequence(Rule_test2_0.java:8)
	at com.ericsson.ruletest.debug.Rule_test2_0ConsequenceInvoker.evaluate(Rule_test2_0ConsequenceInvoker.java:22)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:437)
	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:269)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:256)
	at com.ericsson.ruletest.TestDriver.main(TestDriver.java:26)

The given test case is the the simplified from my production code.

--------------- test.drl ------------------------

package com.ericsson.ruletest.debug

import com.ericsson.ruletest.Fact;

rule "test1"
	salience 10
	no-loop true
    when
        input:Fact();
    then
    	retract(input);
	assert(input);
end;


rule "test2"
	salience 0
	no-loop true
    when
        input:Fact();
    then
	retract(input);
end;




-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:56:42 2006
From: jira-events at jboss.com (Leo Liang (JIRA))
Date: Sat, 30 Sep 2006 00:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-506) Exception thrown
 when retract, reassert and retract again
In-Reply-To: <18021626.1159592202304.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13494388.1159592202496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-506?page=all ]

Leo Liang updated JBRULES-506:
------------------------------

    Attachment: TestDriver.java

> Exception thrown when retract, reassert and retract again
> ---------------------------------------------------------
>
>                 Key: JBRULES-506
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-506
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.4, 3.0.1
>            Reporter: Leo Liang
>         Assigned To: Mark Proctor
>         Attachments: Fact.java, test.drl, TestDriver.java
>
>
> In one rule retract the object and re-assert it, then retract the object again in the following activated rule. A null pointer exception will occur at this time.
> java.lang.NullPointerException
> 	at org.drools.reteoo.TerminalNode.retractTuple(TerminalNode.java:216)
> 	at org.drools.reteoo.LeftInputAdapterNode.retractObject(LeftInputAdapterNode.java:207)
> 	at org.drools.reteoo.ObjectSource.propagateRetractObject(ObjectSource.java:141)
> 	at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:180)
> 	at org.drools.reteoo.Rete.retractObject(Rete.java:150)
> 	at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:207)
> 	at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:77)
> 	at org.drools.common.AbstractWorkingMemory.retractObject(AbstractWorkingMemory.java:668)
> 	at org.drools.base.DefaultKnowledgeHelper.retractObject(DefaultKnowledgeHelper.java:86)
> 	at com.ericsson.ruletest.debug.Rule_test2_0.consequence(Rule_test2_0.java:8)
> 	at com.ericsson.ruletest.debug.Rule_test2_0ConsequenceInvoker.evaluate(Rule_test2_0ConsequenceInvoker.java:22)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:437)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:269)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:256)
> 	at com.ericsson.ruletest.TestDriver.main(TestDriver.java:26)
> The given test case is the the simplified from my production code.
> --------------- test.drl ------------------------
> package com.ericsson.ruletest.debug
> import com.ericsson.ruletest.Fact;
> rule "test1"
> 	salience 10
> 	no-loop true
>     when
>         input:Fact();
>     then
>     	retract(input);
> 	assert(input);
> end;
> rule "test2"
> 	salience 0
> 	no-loop true
>     when
>         input:Fact();
>     then
> 	retract(input);
> end;

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:56:42 2006
From: jira-events at jboss.com (Leo Liang (JIRA))
Date: Sat, 30 Sep 2006 00:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-506) Exception thrown
 when retract, reassert and retract again
In-Reply-To: <18021626.1159592202304.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20434750.1159592202710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-506?page=all ]

Leo Liang updated JBRULES-506:
------------------------------

    Attachment: Fact.java
                test.drl

> Exception thrown when retract, reassert and retract again
> ---------------------------------------------------------
>
>                 Key: JBRULES-506
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-506
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.4, 3.0.1
>            Reporter: Leo Liang
>         Assigned To: Mark Proctor
>         Attachments: Fact.java, test.drl, TestDriver.java
>
>
> In one rule retract the object and re-assert it, then retract the object again in the following activated rule. A null pointer exception will occur at this time.
> java.lang.NullPointerException
> 	at org.drools.reteoo.TerminalNode.retractTuple(TerminalNode.java:216)
> 	at org.drools.reteoo.LeftInputAdapterNode.retractObject(LeftInputAdapterNode.java:207)
> 	at org.drools.reteoo.ObjectSource.propagateRetractObject(ObjectSource.java:141)
> 	at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:180)
> 	at org.drools.reteoo.Rete.retractObject(Rete.java:150)
> 	at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:207)
> 	at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:77)
> 	at org.drools.common.AbstractWorkingMemory.retractObject(AbstractWorkingMemory.java:668)
> 	at org.drools.base.DefaultKnowledgeHelper.retractObject(DefaultKnowledgeHelper.java:86)
> 	at com.ericsson.ruletest.debug.Rule_test2_0.consequence(Rule_test2_0.java:8)
> 	at com.ericsson.ruletest.debug.Rule_test2_0ConsequenceInvoker.evaluate(Rule_test2_0ConsequenceInvoker.java:22)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:437)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:269)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:256)
> 	at com.ericsson.ruletest.TestDriver.main(TestDriver.java:26)
> The given test case is the the simplified from my production code.
> --------------- test.drl ------------------------
> package com.ericsson.ruletest.debug
> import com.ericsson.ruletest.Fact;
> rule "test1"
> 	salience 10
> 	no-loop true
>     when
>         input:Fact();
>     then
>     	retract(input);
> 	assert(input);
> end;
> rule "test2"
> 	salience 0
> 	no-loop true
>     when
>         input:Fact();
>     then
> 	retract(input);
> end;

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 03:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 03:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15441859.1159601921709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3699?page=all ]

Dimitris Andreadis closed JBAS-3699.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

OOMEs gone.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 04:32:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 04:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3676) Upgrade jboss-common
	to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18379539.1159605162235.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3676?page=all ]

Dimitris Andreadis closed JBAS-3676.
------------------------------------

    Resolution: Done

Done

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Sat Sep 30 06:26:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 06:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-561) Write a simple
 example
 (distributed topic) and include it in the set shipped with the release
In-Reply-To: <27083718.1159475022538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24260273.1159612002150.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-561?page=all ]

Ovidiu Feodorov updated JBMESSAGING-561:
----------------------------------------

    Summary: Write a simple example (distributed topic) and include it in the set shipped with the release  (was: Write two simple examples (distributed queue/topic) and include them in the set shipped with the release)

> Write a simple example (distributed topic) and include it in the set shipped with the release
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-561
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-561
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 06:26:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 06:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-562) Adjust the
 installation script to support a clustered installation
In-Reply-To: <2558336.1159475381657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26410722.1159612002297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-562?page=all ]

Ovidiu Feodorov closed JBMESSAGING-562.
---------------------------------------

    Resolution: Done

> Adjust the installation script to support a clustered installation
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-562
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-562
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 06:29:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 06:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-566) Decide on
 validity of
 DurableSubscriberTest.testDurableSubscriptionDifferentNoLocal()
Message-ID: <32984702.1159612182070.JavaMail.jira@cloud.prod.atl2.jboss.com>

Decide on validity of DurableSubscriberTest.testDurableSubscriptionDifferentNoLocal()
-------------------------------------------------------------------------------------

                 Key: JBMESSAGING-566
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-566
             Project: JBoss Messaging
          Issue Type: Task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Alpha2


DurableSubscriberTest.testDurableSubscriptionDifferentNoLocal() is temporarily commented out until its validity is established. Re-enable the test or delete it, depending on the conclusion.


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 07:06:41 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Sat, 30 Sep 2006 07:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-157) Socket listeners
 might introduce
 a port conflict when reinstantiated by the controlling GpListener at
 parameter reload time
Message-ID: <16566909.1159614401806.JavaMail.jira@cloud.prod.atl2.jboss.com>

Socket listeners might introduce a port conflict when reinstantiated by the controlling GpListener at parameter reload time
---------------------------------------------------------------------------------------------------------------------------

                 Key: JBESB-157
                 URL: http://jira.jboss.com/jira/browse/JBESB-157
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ESB Core
            Reporter: Esteban Schifman
         Assigned To: Esteban Schifman
             Fix For: 4.0


GpListener has at present two mechanisms to reload it's configuration parameters:  a) timer driven  2) message driven.

At parameter reload time, the controlling instance of GpListener will try to instantiate new child processes according to the new configuration values.  It will allow active child threads to gracetully finish.

New listener classes that are accepting connections on specific sockets will have a conflict when the new instance tries to listen on a port that is being used by the active instance.


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:11:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-563) Update the
 documentation with a Clustering Intro
In-Reply-To: <284336.1159475381808.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18701286.1159618301669.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-563?page=all ]

Ovidiu Feodorov updated JBMESSAGING-563:
----------------------------------------

    Assignee: Tim Fox  (was: Ovidiu Feodorov)

> Update the documentation with a Clustering Intro
> ------------------------------------------------
>
>                 Key: JBMESSAGING-563
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-563
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:11:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-563) Update the
 documentation with a Clustering Intro
In-Reply-To: <284336.1159475381808.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14220693.1159618301841.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-563?page=all ]

Ovidiu Feodorov closed JBMESSAGING-563.
---------------------------------------

    Resolution: Done

> Update the documentation with a Clustering Intro
> ------------------------------------------------
>
>                 Key: JBMESSAGING-563
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-563
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:11:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-561) Write a simple
 example
 (distributed topic) and include it in the set shipped with the release
In-Reply-To: <27083718.1159475022538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25244249.1159618301966.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-561?page=all ]

Ovidiu Feodorov closed JBMESSAGING-561.
---------------------------------------

    Resolution: Done

> Write a simple example (distributed topic) and include it in the set shipped with the release
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-561
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-561
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:26:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-444) Release
	1.2.0.Alpha1
In-Reply-To: <4902145.1153769531475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18271426.1159619201651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-444?page=all ]

Ovidiu Feodorov closed JBMESSAGING-444.
---------------------------------------

    Resolution: Done

> Release 1.2.0.Alpha1
> --------------------
>
>                 Key: JBMESSAGING-444
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-444
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 12:17:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-333) Provide SO_LINGER for
	TCP/TCP_NIO
Message-ID: <11431434.1159633061692.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide SO_LINGER for TCP/TCP_NIO
---------------------------------

                 Key: JGRP-333
                 URL: http://jira.jboss.com/jira/browse/JGRP-333
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.4


Implemented as 'linger' in TCP and TCP_NIO

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 12:20:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-333) Provide SO_LINGER
	for TCP/TCP_NIO
In-Reply-To: <11431434.1159633061692.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19843082.1159633241508.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-333?page=all ]

Bela Ban resolved JGRP-333.
---------------------------

    Resolution: Done

> Provide SO_LINGER for TCP/TCP_NIO
> ---------------------------------
>
>                 Key: JGRP-333
>                 URL: http://jira.jboss.com/jira/browse/JGRP-333
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> Implemented as 'linger' in TCP and TCP_NIO

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 12:20:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-334) Option to pick random
 port in TCP/TCP_NIO
Message-ID: <20108966.1159633241624.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

        


From jira-events at jboss.com  Sat Sep 30 12:23:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-334) Option to pick
 random port in TCP/TCP_NIO
In-Reply-To: <20108966.1159633241624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18821183.1159633421616.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-334?page=comments#action_12344364 ] 
            
Bela Ban commented on JGRP-334:
-------------------------------

Of course, this works only with MPING or TCPGOSSIP. We need to have a little sanity test which terminates on startup if we have an incorrect discovery protocol (e.g. TCPPING) and start_port is not set !

> 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

        


From jira-events at jboss.com  Sat Sep 30 14:05:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-559) Add a
 4.0.5.CR1 EJB3 smoke test
In-Reply-To: <31350343.1159295201477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11854397.1159639541802.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-559?page=all ]

Ovidiu Feodorov updated JBMESSAGING-559:
----------------------------------------

    Fix Version/s: 1.0.1.GA
                       (was: 1.0.1.CR6)

> Add a 4.0.5.CR1 EJB3 smoke test
> -------------------------------
>
>                 Key: JBMESSAGING-559
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-559
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.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

        


From jira-events at jboss.com  Sat Sep 30 14:05:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8126648.1159639541961.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-564:
-----------------------------------------

             

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:05:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:05:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <207083.1159639542174.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Ovidiu Feodorov updated JBMESSAGING-564:
----------------------------------------

    Fix Version/s: 1.0.1.GA
                       (was: 1.0.1.CR6)
                       (was: 1.2.0.Alpha1)

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:08:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-564)
 Session.unsubscribe() leaves
 an active associated consumer (durable subscriber) in an undefined state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3594189.1159639721564.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Ovidiu Feodorov closed JBMESSAGING-564.
---------------------------------------

    Resolution: Won't Fix

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:26:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
In-Reply-To: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11256934.1159640801625.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3727?page=all ]

Dimitris Andreadis reassigned JBAS-3727:
----------------------------------------

    Assignee: Dimitris Andreadis  (was: Scott M Stark)

> NPE on context classloader changing in EJB container when caller doesn't have a context classloader
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3727
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> The following code in org.jboss.ejb.Container
> doesn't work if the caller doesn't have a context classloader,
> e.g. it is using the bootstrap classloader as its classloader on the Sun JDK
>       ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
>       long start = System.currentTimeMillis();
>       Method m = null;
>       boolean setCl = false;
>       Object type = null;
>       String contextID = getJaccContextID();
>       try
>       {
>          if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
>          {
>             setCl = true;
>             SecurityActions.setContextClassLoader(this.classLoader);
>          }
> The classloaders should be reversed, since the ejb classloader can never be null.
> Is there a reason for this optimization? I'd imagine the comparison of classloaders
> is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:35:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
In-Reply-To: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18379860.1159641341689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3727?page=all ]

Dimitris Andreadis updated JBAS-3727:
-------------------------------------

    Affects Version/s: JBossAS-3.2.8.SP1

> NPE on context classloader changing in EJB container when caller doesn't have a context classloader
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3727
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> The following code in org.jboss.ejb.Container
> doesn't work if the caller doesn't have a context classloader,
> e.g. it is using the bootstrap classloader as its classloader on the Sun JDK
>       ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
>       long start = System.currentTimeMillis();
>       Method m = null;
>       boolean setCl = false;
>       Object type = null;
>       String contextID = getJaccContextID();
>       try
>       {
>          if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
>          {
>             setCl = true;
>             SecurityActions.setContextClassLoader(this.classLoader);
>          }
> The classloaders should be reversed, since the ejb classloader can never be null.
> Is there a reason for this optimization? I'd imagine the comparison of classloaders
> is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3732) Remove
 classloader.equals optimization
Message-ID: <3748725.1159641521636.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove classloader.equals optimization
--------------------------------------

                 Key: JBAS-3732
                 URL: http://jira.jboss.com/jira/browse/JBAS-3732
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.6.CR1


According to the parent issue, the classloader check optimization is probably unecessary, so remove it in the next CR release.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3732) Remove
 classloader.equals optimization
In-Reply-To: <3748725.1159641521636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9029583.1159641521745.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3732?page=all ]

Dimitris Andreadis updated JBAS-3732:
-------------------------------------

    Priority: Minor  (was: Major)

> Remove classloader.equals optimization
> --------------------------------------
>
>                 Key: JBAS-3732
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3732
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> According to the parent issue, the classloader check optimization is probably unecessary, so remove it in the next CR release.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
In-Reply-To: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25361105.1159641521940.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3727?page=all ]

Dimitris Andreadis closed JBAS-3727.
------------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2
       Resolution: Done

I switched the equals order and made a subtasks to try remove the optimazation in the next CR release.

> NPE on context classloader changing in EJB container when caller doesn't have a context classloader
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3727
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>
> The following code in org.jboss.ejb.Container
> doesn't work if the caller doesn't have a context classloader,
> e.g. it is using the bootstrap classloader as its classloader on the Sun JDK
>       ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
>       long start = System.currentTimeMillis();
>       Method m = null;
>       boolean setCl = false;
>       Object type = null;
>       String contextID = getJaccContextID();
>       try
>       {
>          if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
>          {
>             setCl = true;
>             SecurityActions.setContextClassLoader(this.classLoader);
>          }
> The classloaders should be reversed, since the ejb classloader can never be null.
> Is there a reason for this optimization? I'd imagine the comparison of classloaders
> is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:56:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3731) The default
 ServiceBindingManager's sample bindings file should override JBoss
 Messaging's Connector configuration
In-Reply-To: <9539431.1159591662176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6850820.1159642601536.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3731?page=all ]

Dimitris Andreadis reassigned JBAS-3731:
----------------------------------------

    Assignee: Dimitris Andreadis

> The default ServiceBindingManager's sample bindings file should override JBoss Messaging's Connector configuration
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3731
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3731
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> The default ServiceBindingManager's sample bindings file (${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml) should contain <service-config> entries that would override JBoss Messaging's Connector configuration.
> The <service-config> should be present in all <server> bindings ("ports-default", "ports-01", "ports-02", "ports-03").
> Suggested <service-config> entries:
> "ports-default":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4457/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4457"/>
>  </service-config></server>
> "ports-01":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4557/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4557"/>
>  </service-config></server>
> "ports-02":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4657/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4657"/>
>  </service-config></server>
> "ports-03":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4757/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4757"/>
>  </service-config></server>

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:02:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 15:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3731) The default
 ServiceBindingManager's sample bindings file should override JBoss
 Messaging's Connector configuration
In-Reply-To: <9539431.1159591662176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4093988.1159642961526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3731?page=all ]

Dimitris Andreadis closed JBAS-3731.
------------------------------------

    Resolution: Done

Added the bindings as suggested in Branch_4_0 and HEAD

> The default ServiceBindingManager's sample bindings file should override JBoss Messaging's Connector configuration
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3731
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3731
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> The default ServiceBindingManager's sample bindings file (${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml) should contain <service-config> entries that would override JBoss Messaging's Connector configuration.
> The <service-config> should be present in all <server> bindings ("ports-default", "ports-01", "ports-02", "ports-03").
> Suggested <service-config> entries:
> "ports-default":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4457/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4457"/>
>  </service-config></server>
> "ports-01":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4557/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4557"/>
>  </service-config></server>
> "ports-02":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4657/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4657"/>
>  </service-config></server>
> "ports-03":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4757/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4757"/>
>  </service-config></server>

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:39:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-158) Update manuals on
 EPR and Message changes.
Message-ID: <21331127.1159645181720.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update manuals on EPR and Message changes.
------------------------------------------

                 Key: JBESB-158
                 URL: http://jira.jboss.com/jira/browse/JBESB-158
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Sat Sep 30 15:47:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-159) Refactor modules
Message-ID: <21094178.1159645661642.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor modules
----------------

                 Key: JBESB-159
                 URL: http://jira.jboss.com/jira/browse/JBESB-159
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.1


Do we need 3 modules for the core ESB?

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:59:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-148) Glossary of terms
In-Reply-To: <28492607.1159188841189.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15034766.1159646381741.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-148?page=all ]

Mark Little closed JBESB-148.
-----------------------------

    Resolution: Duplicate Issue

> Glossary of terms
> -----------------
>
>                 Key: JBESB-148
>                 URL: http://jira.jboss.com/jira/browse/JBESB-148
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> We need a glossary of terms in the documentation and/or wiki.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:59:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-86) Identify what QA
 and unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27290196.1159646381857.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-86?page=comments#action_12344367 ] 
            
Mark Little commented on JBESB-86:
----------------------------------

We will start with automating the trailblazer into the QA and enable different configurations/deployments of it to test aspects of the system. From there we'll add new scenarios.

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:59:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:59:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-86) Identify what QA and
 unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32935923.1159646382059.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-86?page=all ]

Mark Little closed JBESB-86.
----------------------------

    Resolution: Done

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 4 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 16:35:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 16:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27001505.1159648542089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little closed JBESB-118.
-----------------------------

    Resolution: Done

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 16:35:42 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 30 Sep 2006 16:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (SWAP-17) Outline plan for
	project PBS
Message-ID: <21301483.1159648542238.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SWAP-17?page=all ]

Roy Russo resolved SWAP-17.
---------------------------

    Fix Version/s: PortletSwap 2.0
       Resolution: Done

Moved to: https://prp.dev.java.net/

> Outline plan for project PBS
> ----------------------------
>
>                 Key: SWAP-17
>                 URL: http://jira.jboss.com/jira/browse/SWAP-17
>             Project: PortletSwap
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Infrastructure
>    Affects Versions: PortletSwap 2.0
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: PortletSwap 2.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

        


From jira-events at jboss.com  Sat Sep 30 16:45:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 16:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-140) Move samples out of
	docs
In-Reply-To: <19507011.1158670556332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20162596.1159649141768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-140?page=all ]

Mark Little reassigned JBESB-140:
---------------------------------

    Assignee: Mark Little  (was: Daniel Brum)

> Move samples out of docs
> ------------------------
>
>                 Key: JBESB-140
>                 URL: http://jira.jboss.com/jira/browse/JBESB-140
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core, Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>
> The trailblazer needs to be more prominent in the distribution and source. Let's move it out of the docs directory and into it's own, at the same level as docs.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 16:59:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Sat, 30 Sep 2006 16:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
In-Reply-To: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6508507.1159649981768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1045?page=all ]

Boleslaw Dawidowicz reopened JBPORTAL-1045:
-------------------------------------------

             

> port OpenDS integration from JBoss AS testsuite to portal testsuite
> -------------------------------------------------------------------
>
>                 Key: JBPORTAL-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Test
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 3 hours, 16 minutes
>
> Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:02:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Sat, 30 Sep 2006 17:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
In-Reply-To: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3872190.1159650161502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1045?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1045.
-------------------------------------------

    Resolution: Rejected

OpenDS is jdk5 dependant while portal need to be 1.4 compatible

> port OpenDS integration from JBoss AS testsuite to portal testsuite
> -------------------------------------------------------------------
>
>                 Key: JBPORTAL-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Test
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 3 hours, 16 minutes
>
> Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:05:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Sat, 30 Sep 2006 17:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1062) ApacheDS for
 ldap integration testing
Message-ID: <17861467.1159650341688.JavaMail.jira@cloud.prod.atl2.jboss.com>

ApacheDS for ldap integration testing
-------------------------------------

                 Key: JBPORTAL-1062
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1062
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Test
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- make embedded ApacheDS  service to use in testing framework

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:17:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-160) Unify config
	directories
Message-ID: <31047871.1159651061661.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unify config directories
------------------------

                 Key: JBESB-160
                 URL: http://jira.jboss.com/jira/browse/JBESB-160
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


docs/Install/config and config? Why two?

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:20:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-140) Move samples out of
	docs
In-Reply-To: <19507011.1158670556332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10619071.1159651241622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-140?page=all ]

Mark Little closed JBESB-140.
-----------------------------

    Resolution: Done

> Move samples out of docs
> ------------------------
>
>                 Key: JBESB-140
>                 URL: http://jira.jboss.com/jira/browse/JBESB-140
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core, Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 15 minutes
>  Remaining Estimate: 0 minutes
>
> The trailblazer needs to be more prominent in the distribution and source. Let's move it out of the docs directory and into it's own, at the same level as docs.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:23:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-161) Configuration is too
	confusing
Message-ID: <17897435.1159651421634.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configuration is too confusing
------------------------------

                 Key: JBESB-161
                 URL: http://jira.jboss.com/jira/browse/JBESB-161
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


Configuration information for the runtime system, for the object store, for the listeners and for the trailmap is far too confusing. We need one way of doing things. Use the PropertyManager for deployment configuration.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:26:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-162) Where possible,
 configure the trailmap using PropertyManager
Message-ID: <16179927.1159651601631.JavaMail.jira@cloud.prod.atl2.jboss.com>

Where possible, configure the trailmap using PropertyManager
------------------------------------------------------------

                 Key: JBESB-162
                 URL: http://jira.jboss.com/jira/browse/JBESB-162
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
             Fix For: 4.0


Can we have a loanbroker XML configuration file and use the PropertyManager?

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:38:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-163) Install dir not
 copied into distribution
Message-ID: <11073750.1159652321519.JavaMail.jira@cloud.prod.atl2.jboss.com>

Install dir not copied into distribution
----------------------------------------

                 Key: JBESB-163
                 URL: http://jira.jboss.com/jira/browse/JBESB-163
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Distribution, Documentation, ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


The Install dir in docs is not copied into the distribution.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:59:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-163) Install dir not
 copied into distribution
In-Reply-To: <11073750.1159652321519.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4391016.1159653581689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-163?page=all ]

Mark Little closed JBESB-163.
-----------------------------

    Resolution: Done

> Install dir not copied into distribution
> ----------------------------------------
>
>                 Key: JBESB-163
>                 URL: http://jira.jboss.com/jira/browse/JBESB-163
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Distribution, ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 10 minutes
>  Remaining Estimate: 0 minutes
>
> The Install dir in docs is not copied into the distribution.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 18:05:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 18:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4784320.1159653941778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little reassigned JBESB-104:
---------------------------------

    Assignee: Kurt Stam  (was: Kevin Conner)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Blocker
>             Fix For: 4.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

        


From jira-events at jboss.com  Sat Sep 30 18:08:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 18:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-150) There are too many
 magic numbers/strings in the code
In-Reply-To: <2024480.1159360722469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6792639.1159654121715.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-150?page=all ]

Mark Little reassigned JBESB-150:
---------------------------------

    Assignee: Kurt Stam  (was: Mark Little)

> There are too many magic numbers/strings in the code
> ----------------------------------------------------
>
>                 Key: JBESB-150
>                 URL: http://jira.jboss.com/jira/browse/JBESB-150
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.0
>
>
> Particularly in the property space.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 18:08:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 18:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-153) Make all
 configuration attribute names have consistent format
In-Reply-To: <25928255.1159443281619.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18273696.1159654121947.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-153?page=all ]

Mark Little reassigned JBESB-153:
---------------------------------

    Assignee: Kurt Stam  (was: Mark Little)

> Make all configuration attribute names have consistent format
> -------------------------------------------------------------
>
>                 Key: JBESB-153
>                 URL: http://jira.jboss.com/jira/browse/JBESB-153
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.0
>
>
> org.jboss.soa.esb as the root of all names.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:21:18 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Fri, 1 Sep 2006 03:21:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-595) Fix the spring http
 performance tests.
In-Reply-To: <15640238.1156986823869.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4297408.1157095278193.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-595?page=all ]

Ron Sigal closed JBREM-595.
---------------------------

    Resolution: Done

The spring_http test still failed randomly after the changes that allowed the spring_rmi test to work.  Some clients were failing with "address in use" BindExceptions when they tried to call a method on the server proxy.  It looks like machine (Windows) was running out of available ports, even when the MaxUserPort tcp parameter was set to 64000.  The failure was corrected by putting method invocations in a loop that runs until the invocation succeeds.

> Fix the spring http performance tests.
> --------------------------------------
>
>                 Key: JBREM-595
>                 URL: http://jira.jboss.com/jira/browse/JBREM-595
>             Project: JBoss Remoting
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.Beta1 (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The changes made for the spring rmi performance test need to be applied to the spring http tests. See JBREM-592 for more information.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:39:18 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 03:39:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-293) Support for more
	system properties
Message-ID: <26071221.1157096358240.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support for more system properties
----------------------------------

                 Key: JGRP-293
                 URL: http://jira.jboss.com/jira/browse/JGRP-293
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Optional
             Fix For: 2.4


${jboss.mcast.ip.ttl:2}

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:45:17 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Fri, 1 Sep 2006 03:45:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-358) Look into WTP
 Facet's as a
 unified api for handling "lib" and "project" configuration
Message-ID: <23472544.1157096717802.JavaMail.jira@cloud.prod.atl2.jboss.com>

Look into WTP Facet's as a unified api for handling "lib" and "project" configuration
-------------------------------------------------------------------------------------

                 Key: JBIDE-358
                 URL: http://jira.jboss.com/jira/browse/JBIDE-358
             Project: JBoss IDE
          Issue Type: Task
    Affects Versions: 2.0.0.Beta1
            Reporter: Max Andersen
         Assigned To: Marshall Culpepper
             Fix For: 2.0.0.Beta2




-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:51:18 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 1 Sep 2006 03:51:18 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18269889.1157097078124.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-79?page=all ]

Alexey Loubyansky reassigned JBXB-79:
-------------------------------------

    Assignee: Alexey Loubyansky

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:53:17 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 1 Sep 2006 03:53:17 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24557531.1157097197066.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBXB-79?page=comments#action_12342577 ] 
            
Alexey Loubyansky commented on JBXB-79:
---------------------------------------

The problem occurs during unmarshalling. An instance of the class is created and then array items are appended to the array. The fix would be to ignore the initialization you do in the class initializer and just set the unmarshalled value. That's what I meant.

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 03:59:16 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 03:59:16 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-294) Introduce system
 property to
 preserve backwards compatibility of Util.object{To,From}ByteBuffer()
Message-ID: <3922788.1157097556700.JavaMail.jira@cloud.prod.atl2.jboss.com>

Introduce system property to preserve backwards compatibility of Util.object{To,From}ByteBuffer()
-------------------------------------------------------------------------------------------------

                 Key: JGRP-294
                 URL: http://jira.jboss.com/jira/browse/JGRP-294
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


Because of the HAPartitionImpl marshalling issue we found in 4.0.x last
night, 2.4 is not going to work in 4.0.2 (or any 4.0 before 4.0.5.GA).

A workaround for this is to check a system property in a static
initializer in Util. If "compatibility mode" or whatever, fall back to
the old Util.objectTo/FromByteBuffer impl. Users of old AS releases
would have to set this property to use 2.4 or higher.

But, it seems I have system properties on the brain these days; its
starting to look like a golden hammer, so proceed with caution ;)

BTW, the JIRA to ensure this isn't an issue for 4.0.5.GA is
http://jira.jboss.com/jira/browse/JBAS-3593.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 05:47:20 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 05:47:20 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-294) Introduce system
 property to
 preserve backwards compatibility of Util.object{To,From}ByteBuffer()
In-Reply-To: <3922788.1157097556700.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5662868.1157104040545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-294?page=all ]

Bela Ban resolved JGRP-294.
---------------------------

    Resolution: Done

> Introduce system property to preserve backwards compatibility of Util.object{To,From}ByteBuffer()
> -------------------------------------------------------------------------------------------------
>
>                 Key: JGRP-294
>                 URL: http://jira.jboss.com/jira/browse/JGRP-294
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Because of the HAPartitionImpl marshalling issue we found in 4.0.x last
> night, 2.4 is not going to work in 4.0.2 (or any 4.0 before 4.0.5.GA).
> A workaround for this is to check a system property in a static
> initializer in Util. If "compatibility mode" or whatever, fall back to
> the old Util.objectTo/FromByteBuffer impl. Users of old AS releases
> would have to set this property to use 2.4 or higher.
> But, it seems I have system properties on the brain these days; its
> starting to look like a golden hammer, so proceed with caution ;)
> BTW, the JIRA to ensure this isn't an issue for 4.0.5.GA is
> http://jira.jboss.com/jira/browse/JBAS-3593.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 06:27:21 2006
From: jira-events at jboss.com (Stefan Kassal (JIRA))
Date: Fri, 1 Sep 2006 06:27:21 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-295) DistributedHashtable
 and ChannelFactory with XML config file
Message-ID: <32773016.1157106441257.JavaMail.jira@cloud.prod.atl2.jboss.com>

DistributedHashtable and ChannelFactory with XML config file
------------------------------------------------------------

                 Key: JGRP-295
                 URL: http://jira.jboss.com/jira/browse/JGRP-295
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4
            Reporter: Stefan Kassal
         Assigned To: Bela Ban


I think I have found an issue with DistributedHashtables (jgroups 2.4CR2)
I have a XML file containing the protocol stack and create a ChannelFactory with that file.

ChannelFactory  factory=new JChannelFactory(new File(configFilePathM));
	
The DistributedHashtable is created with

DistributedHashtable distHashM = new DistributedHashtable(distChannelNameM,factory,channelProps,true,TIMEOUT);
	
The problem is that the constructor of the DistributedHashtable class which I want to use uses the following:

channel=factory != null ? factory.createChannel(properties) : new JChannel(properties);
	
That means it always tries to uses the properties to create the channel and you cannot force it to use the configuration of the factory.
This could be solved in a way that you check if the properties is null and if it is you call  factory.createChannel()

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 06:55:44 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Fri, 1 Sep 2006 06:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3595) Tomcat allows http
 access with transport guarantie CONFIDENTIAL
Message-ID: <5034484.1157108144114.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tomcat allows http access with transport guarantie CONFIDENTIAL
---------------------------------------------------------------

                 Key: JBAS-3595
                 URL: http://jira.jboss.com/jira/browse/JBAS-3595
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Thomas Diesler
             Fix For: JBossAS-5.0.0.Beta


The generated web.xml contains CONFIDENTIAL. Access via http:// should be denied.
This woks in Branch_4_0

/home/tdiesler/svn/jbossws/trunk/src/test
[tdiesler at tdvaio test]$ ant -Dtest=org.jboss.test.ws.samples.secureejb.SecureEJBTestCase one-test

one-test:
    [junit] Running org.jboss.test.ws.samples.secureejb.SecureEJBTestCase
    [junit] Tests run: 5, Failures: 1, Errors: 0, Time elapsed: 5.452 sec
    [junit] Test org.jboss.test.ws.samples.secureejb.SecureEJBTestCase FAILED


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 07:41:44 2006
From: jira-events at jboss.com (Ales Justin (JIRA))
Date: Fri, 1 Sep 2006 07:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMICROCONT-35) Allow retrieval
 of the collection instance from the bean
Message-ID: <8247706.1157110904615.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMICROCONT-35?page=all ]

Ales Justin closed JBMICROCONT-35.
----------------------------------

    Resolution: Done

Fixed Custom[Collection|List|Map|Set] so that default constructor doesn't set preinstantiated = true.
Added xml files for all preinstantiated tests.
Since preinstantiated lookup must pass through MetaDataVisitor.initialVisit(), instantiation method with KernelController was added.

> Allow retrieval of the collection instance from the bean
> --------------------------------------------------------
>
>                 Key: JBMICROCONT-35
>                 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-35
>             Project: JBoss MicroContainer
>          Issue Type: Task
>          Components: MetaData
>            Reporter: Adrian Brock
>         Assigned To: Ales Justin
>             Fix For:  JBossMC_2_0_0M1
>
>
> See org.jboss.test.kernel.config.test.CollectionTestCase#TODOtestCustomCollectionPreInstantiated
> Same issues apply to Lists, Sets, Maps, Arrays, etc.
> i.e. If the bean already has a collection value for the property that can be
> retrieved using the getter, we should be able to use that collection instance.
> Need to think about the configuration options and rules.
> Current rules are:
> 1) Use class specified in metadata
> 2) Use class specified on setter (if not an interface)
> 3) Use ArrayList

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 07:49:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 1 Sep 2006 07:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-472) Correct lines in
 RHS to match up with lines in rule source
Message-ID: <14103178.1157111383787.JavaMail.jira@cloud.prod.atl2.jboss.com>

Correct lines in RHS to match up with lines in rule source
----------------------------------------------------------

                 Key: JBRULES-472
                 URL: http://jira.jboss.com/jira/browse/JBRULES-472
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions: 3.0.4
            Reporter: Michael Neale
         Assigned To: Michael Neale
             Fix For: 3.1-m1


This means to calculate the correct line number, and make sure the RHS matches up with it for line number debugging.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 07:53:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 1 Sep 2006 07:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-472) Correct lines in
 RHS to match up with lines in rule source
In-Reply-To: <14103178.1157111383787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24543947.1157111623815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-472?page=all ]

Michael Neale resolved JBRULES-472.
-----------------------------------

    Resolution: Done

> Correct lines in RHS to match up with lines in rule source
> ----------------------------------------------------------
>
>                 Key: JBRULES-472
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-472
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.4
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 3.1-m1
>
>
> This means to calculate the correct line number, and make sure the RHS matches up with it for line number debugging.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 08:31:43 2006
From: jira-events at jboss.com (Christian Buggle (JIRA))
Date: Fri, 1 Sep 2006 08:31:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-45) ehcache-1.1.jar,
 bsh-2.0b1.jar declared in classpath are missing
Message-ID: <4262417.1157113903926.JavaMail.jira@cloud.prod.atl2.jboss.com>

ehcache-1.1.jar, bsh-2.0b1.jar declared in classpath are missing
----------------------------------------------------------------

                 Key: HIBERNATE-45
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-45
             Project: Hibernate
          Issue Type: Bug
         Environment: win32 Eclipse 3.2
            Reporter: Christian Buggle
         Assigned To: Steve Ebersole


There are 2 jars missing which are declared in the classpath of  Plugin 'org.hibernate.eclipse_3.2.0.beta6.jar' and 'org.hibernate.eclipse_3.2.0.beta7.jar'
namely: 
lib/hibernate/ehcache-1.1.jar
lib/tools/bsh-2.0b1.jar

No actual crashes or problems noticed yet. 


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 08:45:43 2006
From: jira-events at jboss.com (Christian Buggle (JIRA))
Date: Fri, 1 Sep 2006 08:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (HIBERNATE-45) ehcache-1.1.jar,
 bsh-2.0b1.jar declared in classpath are missing
In-Reply-To: <4262417.1157113903926.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32414367.1157114743845.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/HIBERNATE-45?page=all ]

Christian Buggle closed HIBERNATE-45.
-------------------------------------

    Resolution: Done

jars are present in beta7

(sorry, mixed something up when double-checking, should haven been triple-checking)

> ehcache-1.1.jar, bsh-2.0b1.jar declared in classpath are missing
> ----------------------------------------------------------------
>
>                 Key: HIBERNATE-45
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-45
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: win32 Eclipse 3.2
>            Reporter: Christian Buggle
>         Assigned To: Steve Ebersole
>
> There are 2 jars missing which are declared in the classpath of  Plugin 'org.hibernate.eclipse_3.2.0.beta6.jar' and 'org.hibernate.eclipse_3.2.0.beta7.jar'
> namely: 
> lib/hibernate/ehcache-1.1.jar
> lib/tools/bsh-2.0b1.jar
> No actual crashes or problems noticed yet. 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 09:51:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 09:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <9302266.1157118703977.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342584 ] 
            
Brian Stansberry commented on JBAS-3345:
----------------------------------------

A big chunk of the tc5 folder is clustering related, and that's in "Don't care anymore" mode as well. Delete away!  :)

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 09:59:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 09:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-295) DistributedHashtable
 and ChannelFactory with XML config file
In-Reply-To: <32773016.1157106441257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30200109.1157119183986.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-295?page=all ]

Bela Ban updated JGRP-295:
--------------------------

    Fix Version/s: 2.4

> DistributedHashtable and ChannelFactory with XML config file
> ------------------------------------------------------------
>
>                 Key: JGRP-295
>                 URL: http://jira.jboss.com/jira/browse/JGRP-295
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Stefan Kassal
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> I think I have found an issue with DistributedHashtables (jgroups 2.4CR2)
> I have a XML file containing the protocol stack and create a ChannelFactory with that file.
> ChannelFactory  factory=new JChannelFactory(new File(configFilePathM));
> 	
> The DistributedHashtable is created with
> DistributedHashtable distHashM = new DistributedHashtable(distChannelNameM,factory,channelProps,true,TIMEOUT);
> 	
> The problem is that the constructor of the DistributedHashtable class which I want to use uses the following:
> channel=factory != null ? factory.createChannel(properties) : new JChannel(properties);
> 	
> That means it always tries to uses the properties to create the channel and you cannot force it to use the configuration of the factory.
> This could be solved in a way that you check if the properties is null and if it is you call  factory.createChannel()

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:01:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 10:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-293) Support for more
 system properties
In-Reply-To: <26071221.1157096358240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13229609.1157119303954.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-293?page=all ]

Bela Ban resolved JGRP-293.
---------------------------

    Resolution: Done

no action required on my side...

> Support for more system properties
> ----------------------------------
>
>                 Key: JGRP-293
>                 URL: http://jira.jboss.com/jira/browse/JGRP-293
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Optional
>             Fix For: 2.4
>
>
> ${jboss.mcast.ip.ttl:2}

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:01:47 2006
From: jira-events at jboss.com (Martin Isheim (JIRA))
Date: Fri, 1 Sep 2006 10:01:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-694) @OneToOne
 relation fails, when foreign key is in inverse side
Message-ID: <26748158.1157119307386.JavaMail.jira@cloud.prod.atl2.jboss.com>

@OneToOne relation fails, when foreign key is in inverse side
-------------------------------------------------------------

                 Key: EJBTHREE-694
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-694
             Project: EJB 3.0
          Issue Type: Bug
          Components: EJB3 Extensions
    Affects Versions: EJB 3.0 RC8 - FD
         Environment: JBoss AS 4.0.4 GA3 with jboss-EJB-3.0_RC8-FD installed as described in the release.
            Reporter: Martin Isheim


I defined a OneToOne relation from "UserEntity" to "PasswordEntity", with the foreign key in the "PasswordEntity" (for historical reasons).
With EntityManager.persist() the entities were inserted into the database, but the foreignKey column in "PasswordEntity" is empty.
Reading the "UserEntity" provides an empty relation.

Here the getter from "UserEntity":    

<code>
 private PasswordEntity password;

@OneToOne(optional = true, cascade = CascadeType.ALL)
    @PrimaryKeyJoinColumn(name = "ENTITYKEY", referencedColumnName = "USERKEY")
    public PasswordEntity getPassword() {
        return password;
    }
</code>

Since the relation is unidirectional, "PaswordEntity" has no getter/setter.
Regards.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:03:44 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Fri, 1 Sep 2006 10:03:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-115) NPE in ViewTopic
In-Reply-To: <1960202.1154560871633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3281417.1157119424163.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-115?page=all ]

Ryszard Kozmik reassigned JBFORUMS-115:
---------------------------------------

    Assignee: Ryszard Kozmik

> NPE in ViewTopic
> ----------------
>
>                 Key: JBFORUMS-115
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-115
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>
> Clicking this link http://forums.proto.jboss.com:8080/portal/index.html?ctrl:cmd=render&ctrl:window=default.default.DefaultCMSPortletWindow&t=12&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2Fviews%2Ftopics%2Fviewtopic_body.jsf , causes whole forums to dissapear and throw this exception:
> 18:06:20,855 ERROR [[/portal-forums]] Exception in FacesServlet
> java.lang.NullPointerException
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:393)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:94)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:128)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContainer.java:521)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.java:433)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInvocation.java:79)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.component.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.component.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.NavigationInterceptor.invoke(NavigationInterceptor.java:76)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.CacheInterceptor.invoke(CacheInterceptor.java:111)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ModesInterceptor.invoke(ModesInterceptor.java:88)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:87)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPostDispatchInterceptor.invoke(SessionPostDispatchInterceptor.java:65)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:129)
>         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.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:101)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
>         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>         at org.jboss.portal.server.app.impl.AbstractRequestContext.include(AbstractRequestContext.java:247)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:73)
>         at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:81)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:79)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPreDispatchInterceptor.invoke(SessionPreDispatchInterceptor.java:94)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.ValveInterceptor.invoke(ValveInterceptor.java:64)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:84)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:68)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:141)
>         at org.jboss.portal.core.command.RenderPageCommand.renderPortlets(RenderPageCommand.java:231)
>         at org.jboss.portal.core.command.RenderPageCommand.execute(RenderPageCommand.java:164)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:58)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:93)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:151)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:77)
>         at org.jboss.portal.core.CoreController.handle(CoreController.java:190)
>         at sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
>         at $Proxy136.handle(Unknown Source)
>         at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:76)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.server.SubjectAssociationInterceptor.invoke(SubjectAssociationInterceptor.java:47)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.PolicyAssociationInterceptor.invoke(PolicyAssociationInterceptor.java:52)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:69)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:184)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:87)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java:75)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:221)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:41:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 10:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-295) DistributedHashtable
 and ChannelFactory with XML config file
In-Reply-To: <32773016.1157106441257.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4956152.1157121704679.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-295?page=all ]

Bela Ban resolved JGRP-295.
---------------------------

    Resolution: Done

done, fixed according to suggested solution. Also updated the javadoc

> DistributedHashtable and ChannelFactory with XML config file
> ------------------------------------------------------------
>
>                 Key: JGRP-295
>                 URL: http://jira.jboss.com/jira/browse/JGRP-295
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>            Reporter: Stefan Kassal
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> I think I have found an issue with DistributedHashtables (jgroups 2.4CR2)
> I have a XML file containing the protocol stack and create a ChannelFactory with that file.
> ChannelFactory  factory=new JChannelFactory(new File(configFilePathM));
> 	
> The DistributedHashtable is created with
> DistributedHashtable distHashM = new DistributedHashtable(distChannelNameM,factory,channelProps,true,TIMEOUT);
> 	
> The problem is that the constructor of the DistributedHashtable class which I want to use uses the following:
> channel=factory != null ? factory.createChannel(properties) : new JChannel(properties);
> 	
> That means it always tries to uses the properties to create the channel and you cannot force it to use the configuration of the factory.
> This could be solved in a way that you check if the properties is null and if it is you call  factory.createChannel()

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:47:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 10:47:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.5.GA
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2580844.1157122063996.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis updated JBAS-3437:
-------------------------------------

     Summary: Get the 3.2-compatibility tests passing for 4.0.5.GA  (was: Get the 3.2-compatibility tests passing for 4.0.5.CR1)
    Assignee:     (was: Prabhat Jha)

> Get the 3.2-compatibility tests passing for 4.0.5.GA
> ----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             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
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:47:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 10:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.5.GA
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17094953.1157122064143.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis updated JBAS-3437:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)

> Get the 3.2-compatibility tests passing for 4.0.5.GA
> ----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             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
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:49:43 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 1 Sep 2006 10:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-744) unify and improve the
 messaging and scheduler implementation
Message-ID: <11413941.1157122183945.JavaMail.jira@cloud.prod.atl2.jboss.com>

unify and improve the messaging and scheduler implementation
------------------------------------------------------------

                 Key: JBPM-744
                 URL: http://jira.jboss.com/jira/browse/JBPM-744
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.2 alpha 1


* unify the scheduler and messaging implementation around the notion of a job
* add support for multiple concurrent threads competing for job execution.  synchronization is to be done by acquiring locks.  acquiring the locks is done with optimistic locking so that it also works for hsqldb


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 10:53:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 1 Sep 2006 10:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-289) Optimize stacks.xml
In-Reply-To: <26182936.1156950223921.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4020918.1157122423830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-289?page=all ]

Bela Ban resolved JGRP-289.
---------------------------

    Resolution: Done

> Optimize stacks.xml
> -------------------
>
>                 Key: JGRP-289
>                 URL: http://jira.jboss.com/jira/browse/JGRP-289
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> We decided we want 4 configurations in stacks.xml:
>    1. fc-fast-minimalthreads
>    2. tcp (copy of the above, with TCP/TCPPING as transport)
>    3. fc-fast-minimalthreads-sync: alternative to #1, without FC and with message bundling disabled
>    4. tcp-sync: copy of #2, without FC and with message bundling disabled
>     * The default stacks (fc-fast and tcp) have FC and message bundling is enabled
>     * All stacks have FLUSH: because we use the Multiplexer, state transfer requires FLUSH
>     * VIEW_SYNC will be removed (because we use FLUSH, this is redundant)
>     * STREAMING_STATE_TRANSFER will be the default state transfer protocol
>           o STATE_TRANSFER is there, but commented
>           o According to Vladimir, these 2 protocols can be used interchangeably, the correct setState() and getState() methods will always be called
>     * For the TCP-based stack
>           o we use TCP_NIO as transport
>           o Discovery is TCPPING: we pass the list of hosts as a system property, default is localhost
>     * Vladimir and I will look at the resulting stacks.xml, and once it is correct, pass it on to Brian and Manik, so it can be tested with clustering and JBossCache

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 11:41:44 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 1 Sep 2006 11:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3596) JNDI static cache
Message-ID: <3008714.1157125304199.JavaMail.jira@cloud.prod.atl2.jboss.com>

JNDI static cache
-----------------

                 Key: JBAS-3596
                 URL: http://jira.jboss.com/jira/browse/JBAS-3596
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.CR1


Having a JNDI caching would improove performance on applications where JNDI is over used.



-- 
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

        


From jira-events at jboss.com  Fri Sep  1 11:51:43 2006
From: jira-events at jboss.com (Thiago Moreira (JIRA))
Date: Fri, 1 Sep 2006 11:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JASSIST-27)
 CodeGen.getArrayWriteOp returns
 a invalid operation for a array of type short
Message-ID: <3166697.1157125903952.JavaMail.jira@cloud.prod.atl2.jboss.com>

CodeGen.getArrayWriteOp returns a invalid operation for a array of type short
-----------------------------------------------------------------------------

                 Key: JASSIST-27
                 URL: http://jira.jboss.com/jira/browse/JASSIST-27
             Project: Javassist
          Issue Type: Bug
            Reporter: Thiago Moreira
         Assigned To: Shigeru Chiba
            Priority: Critical



  The method CodeGen.getArrayWriteOp returns a invalid operation for a array of type short.

  The follow lines fix the bug:

   1655         case SHORT :
   1656             return SASTORE;

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 11:55:43 2006
From: jira-events at jboss.com (Thiago Moreira (JIRA))
Date: Fri, 1 Sep 2006 11:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JASSIST-21) release javassist
 3.1 to ibiblio
Message-ID: <3529547.1157126143831.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JASSIST-21?page=comments#action_12342597 ] 
            
Thiago Moreira commented on JASSIST-21:
---------------------------------------


  The new versions of Javassist could be deployed in ibiblio/maven2 ?!?! 

> release javassist 3.1 to ibiblio
> --------------------------------
>
>                 Key: JASSIST-21
>                 URL: http://jira.jboss.com/jira/browse/JASSIST-21
>             Project: Javassist
>          Issue Type: Task
>         Environment: ibiblio.org/maven2
>            Reporter: Jesse Kuhnert
>
> I have a project using javassist 3.1 and would find it easier to manage if the ibiblio/maven2 repo hosted javassist 3.1 (already has 3.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

        


From jira-events at jboss.com  Fri Sep  1 12:07:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
Message-ID: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
-------------------------------------------------------------------------------

                 Key: JBAS-3597
                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMS service
         Environment: Java Version 1.4.2_09 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Client VM 
Java VM Version 1.4.2_09-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with

Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
	at java.lang.Thread.run(Thread.java:534)

For
MatrixTestContainer(jms_4_0_4_GA)
MatrixTestContainer(jms_4_0_x) 


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:09:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5888950.1157126983887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3597?page=all ]

Dimitris Andreadis updated JBAS-3597:
-------------------------------------

    Component/s: Test Suite

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:09:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3580) Error in
 org.jboss.test.jbossmq.test.UnackedUnitTestCase
In-Reply-To: <7836020.1156800287434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32808130.1157126984063.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3580?page=all ]

Dimitris Andreadis updated JBAS-3580:
-------------------------------------

    Comment: was deleted

> Error in org.jboss.test.jbossmq.test.UnackedUnitTestCase
> --------------------------------------------------------
>
>                 Key: JBAS-3580
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3580
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.CR1
>
>
> This seems like a clean-up problem of a previous test?
> testUnackedDurableTopic
> Error  - The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:93)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:572)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:171)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:643)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:177)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:185)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:15:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3598) Get the 4.0.5.GA
 testsuite-1.4 (JRockit) passing
Message-ID: <31303322.1157127343880.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

        


From jira-events at jboss.com  Fri Sep  1 12:19:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:19:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24789946.1157127584442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3494?page=all ]

Dimitris Andreadis updated JBAS-3494:
-------------------------------------

        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Test Suite
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:19:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:19:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13297509.1157127586069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3494?page=all ]

Dimitris Andreadis updated JBAS-3494:
-------------------------------------

    Issue Type: Task  (was: Bug)

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Test Suite
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:25:50 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:25:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3496) all tests under
 org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
In-Reply-To: <29133751.1155052872676.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26619327.1157127951019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3496?page=all ]

Dimitris Andreadis updated JBAS-3496:
-------------------------------------

           Issue Type: Task  (was: Bug)
        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)

> all tests under org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3496
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3496
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux -dev03 in qa, JRockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> This error does not happen with Sun JDK1.4.
> All test cases under org.jboss.test.cmp2.cmrtree.test have following error:
> Entity with primary key [.1.A.] already exists
> javax.ejb.DuplicateKeyException: Entity with primary key [.1.A.] already exists
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand.beforeInsert(JDBCInsertPKCreateCommand.java:99)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractCreateCommand.execute(JDBCAbstractCreateCommand.java:150)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:587)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:237)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:225)
> 	at org.jboss.ejb.EntityContainer.createLocalHome(EntityContainer.java:625)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
> 	at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
> 	at $Proxy204.create(ILjava.lang.String;Ljava.lang.String;)Lorg.jboss.test.cmp2.cmrtree.ejb.ALocal;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 12:37:45 2006
From: jira-events at jboss.com (Andrig Miller (JIRA))
Date: Fri, 1 Sep 2006 12:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-678) RemoteBinding
 annotation doesn't use the default client binding of the remoting
In-Reply-To: <8002416.1154618891359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27563733.1157128665750.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-678?page=all ]

Andrig Miller updated EJBTHREE-678:
-----------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD

Assign to fix version RC9, because we have a customer that needs this addressed for a current project.

> RemoteBinding annotation doesn't use the default client binding of the remoting
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-678
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. 
> When the jboss remoting service is not configured  using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. 
> The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value).
> I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration.
> The following fixes the issue using the first described approach:
> org.jboss.ejb3.stateless.ProxyDeployer
> public void initializeRemoteBindingMetadata()
>    {
>       remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class);
>       if (remoteBindings == null)
>   ...
>       }
>          else
>          {
>        	 // defaultClientBinding is more accurate that the constant in RemoteBinding 
>              if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) {
>                  binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory());
>              }
>             RemoteBinding[] list = {binding};
>             remoteBindings = new RemoteBindingsImpl(list);
>             advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings);
>          }
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:37:45 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 12:37:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3497) (21) test under
 org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException
 (jrockit)
In-Reply-To: <3943595.1155053113119.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4263597.1157128665925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3497?page=all ]

Dimitris Andreadis updated JBAS-3497:
-------------------------------------

              Summary: (21) test under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException (jrockit)  (was: All tests (21) under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException)
           Issue Type: Task  (was: Bug)
        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)
          Description: 
21 tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:

No such entity!
javax.ejb.ObjectNotFoundException: No such entity!
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
	at org.jboss.ejb.Container.invoke(Container.java:975)

  was:
All tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:

No such entity!
javax.ejb.ObjectNotFoundException: No such entity!
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
	at org.jboss.ejb.Container.invoke(Container.java:975)

Complete error log can be found at http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite-1.4/20060808052249/results/index.html.


> (21) test under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException (jrockit)
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3497
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3497
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux - dev03 in qa, java: Jrockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> 21 tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:
> No such entity!
> javax.ejb.ObjectNotFoundException: No such entity!
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
> 	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:39:44 2006
From: jira-events at jboss.com (Andrig Miller (JIRA))
Date: Fri, 1 Sep 2006 12:39:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-677) EJB3 deployments
 should be bound with rebind instead of bind
In-Reply-To: <7679261.1154618051633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15488968.1157128784535.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-677?page=all ]

Andrig Miller updated EJBTHREE-677:
-----------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD

Assign to fix version RC9, because we have a customer that needs this addressed for a current project.

> EJB3 deployments should be bound with rebind instead of bind
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-677
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-677
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Using bind instead of rebind may cause trouble when the JNDI implementation is persistent (e.g. in an ldap directory) because deploying a previously crashed application will fail. 
> I know that the current situation can also be seen as a feature because the developer cannot deploy two different beans with the same jndi name but this has in my opinion a lesser priority. Further the ejb 2.x stack uses rebind too.
> The request http://jira.jboss.com/jira/browse/EJBTHREE-51 describtes to use Util.rebind()  but in fisheye I saw Util.bind().

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 12:47:44 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Fri, 1 Sep 2006 12:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-630) Portal name
Message-ID: <19819056.1157129264242.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-630?page=comments#action_12342604 ] 
            
Ryszard Kozmik commented on JBPORTAL-630:
-----------------------------------------

Yeah, indeed it can be done like that. Nevertheless, I don't need this feature anymore. As you can see dependant task is resolved :-). Thanks

> Portal name
> -----------
>
>                 Key: JBPORTAL-630
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-630
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryszard Kozmik
>         Assigned To: Julien Viet
>             Fix For: 2.6 Final
>
>
> I need this: req.getPortalContext().getProperty("org.jboss.portal.property.name"));
> to be able to create root link in JBoss Forums.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:11:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 13:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3599) Implement
 MessageListener.block() in HAPartitionImpl
Message-ID: <21857984.1157130703800.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement MessageListener.block() in HAPartitionImpl
----------------------------------------------------

                 Key: JBAS-3599
                 URL: http://jira.jboss.com/jira/browse/JBAS-3599
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


Needed for proper use of JGroups FLUSH.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:23:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:23:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
Message-ID: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>

failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
--------------------------------------------------------------------------------

                 Key: JBAS-3600
                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Sacha Labourey
             Fix For: JBossAS-4.0.5.GA


test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?

Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
javax.management.loading.MLet,
javax.resource.ResourceException,
javax.resource.spi.ConnectionEvent,
javax.resource.spi.InvalidPropertyException,
javax.resource.spi.work.WorkEvent,
javax.security.jacc.EJBMethodPermission,
javax.security.jacc.EJBRoleRefPermission,
javax.security.jacc.WebResourcePermission,
javax.security.jacc.WebRoleRefPermission,
javax.security.jacc.WebUserDataPermission,
javax.xml.registry.JAXRException,
javax.xml.registry.RegistryException,
javax.xml.rpc.JAXRPCException,
javax.xml.rpc.ServiceException,
javax.xml.rpc.soap.SOAPFaultException,
javax.xml.soap.SOAPException
	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 13:23:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:23:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18487801.1157131424292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3600?page=all ]

Dimitris Andreadis reassigned JBAS-3600:
----------------------------------------

    Assignee:     (was: Sacha Labourey)

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 13:31:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:31:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3601) Switch copyright to
 RedHat Middleware LLC
Message-ID: <5022893.1157131903947.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch copyright to RedHat Middleware LLC
-----------------------------------------

                 Key: JBAS-3601
                 URL: http://jira.jboss.com/jira/browse/JBAS-3601
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


Something like:

/*
* JBoss, Home of Professional Open Source
* Copyright 2006, Red Hat Middleware LLC., and individual contributors as indicated 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:37:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:37:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-539) Rig an RI and
 investigate
 the behavior of an XASession in absence of a global transaction
In-Reply-To: <3913639.1157059277734.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4577773.1157132264114.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-539?page=all ]

Ovidiu Feodorov closed JBMESSAGING-539.
---------------------------------------

    Resolution: Won't Fix

Not necessary anymore. JBossMQ does it that way, and Sonic does it the same way, that's good enough.

> Rig an RI and investigate the behavior of an XASession in absence of a global transaction
> -----------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-539
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-539
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Install the Sun's RI and run a simple test case with an XASession sending a message in an absence of a global transaction.
> The test case should determine whether the message is sent to the destination or not when producer.send() completes.
> Add the same test case to Messaging's testsuite.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:43:44 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Fri, 1 Sep 2006 13:43:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-257) Test extender test
 in a scoped environment
Message-ID: <18378733.1157132624056.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-257?page=comments#action_12342611 ] 
            
Kabir Khan commented on JBAOP-257:
----------------------------------

Got the mains stuff working locally testing methods.

Also need to test fields, constructors.

Once I have got the base loaded no parent delegation test passing completely, need to make sure that the correct (i.e. child) copy of per instance, per class, per joinpoint etc. scoped interceptors get called

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:45:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3492) Test Failure with
 JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
In-Reply-To: <31141571.1155047232621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18574087.1157132744759.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3492?page=all ]

Dimitris Andreadis updated JBAS-3492:
-------------------------------------

           Issue Type: Task  (was: Bug)
          Component/s: CMP service
        Fix Version/s: JBossAS-4.0.5.GA
                           (was: JBossAS-4.0.5.CR1)
    Affects Version/s:     (was: JBossAS-4.0.5.CR1)
          Description: 
Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error

Error, bean instance was discarded!
javax.ejb.FinderException: Error, bean instance was discarded!
	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer

On the server log, I see following for the first error in test suite.

2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
onTesterLocal.runtimeExceptionNoTx():
java.lang.RuntimeException: Runtime exception without a transaction
        at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
        at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
        at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
        at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
        at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
        at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
        at org.jboss.ejb.Container.invoke(Container.java:954)

  was:
Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error which can also be found at http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.0-testsuite-1.4/20060807035911/results/index.html.

Error, bean instance was discarded!
javax.ejb.FinderException: Error, bean instance was discarded!
	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer

On the server log, I see following for the first error in test suite.

2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
onTesterLocal.runtimeExceptionNoTx():
java.lang.RuntimeException: Runtime exception without a transaction
        at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
        at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
        at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
        at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
        at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
        at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
        at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
        at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
        at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
        at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
        at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
        at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
        at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
        at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
        at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
        at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
        at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
        at org.jboss.ejb.Container.invoke(Container.java:954)





             Assignee: Alexey Loubyansky

> Test Failure with JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3492
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3492
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, CMP service
>         Environment: linux - dev03 in qa lab, JRockit - java version "1.4.2_11"
>            Reporter: Prabhat Jha
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error
> Error, bean instance was discarded!
> javax.ejb.FinderException: Error, bean instance was discarded!
> 	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer
> On the server log, I see following for the first error in test suite.
> 2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
> 2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
> 2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
> onTesterLocal.runtimeExceptionNoTx():
> java.lang.RuntimeException: Runtime exception without a transaction
>         at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
>         at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
>         at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
>         at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
>         at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
>         at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
>         at org.jboss.ejb.Container.invoke(Container.java:954)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:49:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3602) 3 failing tests
 org.jboss.test.jacc.test (jrockit)
Message-ID: <18072439.1157132983856.JavaMail.jira@cloud.prod.atl2.jboss.com>

3 failing tests org.jboss.test.jacc.test (jrockit)
--------------------------------------------------

                 Key: JBAS-3602
                 URL: http://jira.jboss.com/jira/browse/JBAS-3602
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


org.jboss.test.jacc.test

EJBSpecUnitTestCase(JACC)
EJBSpecUnitTestCase(JACC+SecurityMgr) 

testStressNoJaasCache Failure Thread error count == 0
junit.framework.AssertionFailedError: Thread error count == 0
	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStress(EJBSpecUnitTestCase.java:822)
	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStressNoJaasCache(EJBSpecUnitTestCase.java:842)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

testGetCallerPrincipal Failure Was able to call StatelessSession.echo
junit.framework.AssertionFailedError: Was able to call StatelessSession.echo
	at org.jboss.test.security.test.EJBSpecUnitTestCase.testGetCallerPrincipal(EJBSpecUnitTestCase.java:194)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:51:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:51:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-410) java:/JmsXA
 in no-tx context does not work the same way as JBossMQ
Message-ID: <23024230.1157133104225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-410:
-------------------------------------------

    Assignee: Ovidiu Feodorov  (was: Clebert Suconic)

> java:/JmsXA in no-tx context does not work the same way as JBossMQ
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-410
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR2
>            Reporter: Elias Ross
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory.
> Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility.
> The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced.
>       QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA");
> ...
>       QueueConnection queueConnection = queueCF.createQueueConnection();
>       QueueSession queueSession =
>           queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
>       QueueSender queueSender = queueSession.createSender(queue);
>       ObjectMessage om = queueSession.createObjectMessage();
>       queueSender.send(om);
>       queueSender.close();
>       queueSession.close();
>       queueConnection.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

        


From jira-events at jboss.com  Fri Sep  1 13:55:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 13:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3580) Error in
 org.jboss.test.jbossmq.test.UnackedUnitTestCase
In-Reply-To: <7836020.1156800287434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <419107.1157133343870.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3580?page=all ]

Dimitris Andreadis updated JBAS-3580:
-------------------------------------

      Environment: 
Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


  was:
Java Version 1.4.2_09 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Client VM 
Java VM Version 1.4.2_09-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)
      Description: 
testDummyLast - Error
No durable subscription found for subscription: test
javax.jms.InvalidDestinationException: No durable subscription found for subscription: test
	at org.jboss.mq.sm.AbstractStateManager.getDurableTopic(AbstractStateManager.java:164)
	at org.jboss.mq.server.JMSDestinationManager.getDurableTopic(JMSDestinationManager.java:777)
	at org.jboss.mq.server.JMSServerInterceptorSupport.getDurableTopic(JMSServerInterceptorSupport.java:181)
	at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:207)
	at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:548)
	at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:162)
	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:214)
	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
	at java.lang.Thread.run(Unknown Source)

 

  was:
This seems like a clean-up problem of a previous test?

testUnackedDurableTopic
Error  - The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=null]
	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:93)
	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:572)
	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:171)
	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:643)
	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:177)
	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:185)
	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
	at java.lang.Thread.run(Thread.java:534)




> Error in org.jboss.test.jbossmq.test.UnackedUnitTestCase
> --------------------------------------------------------
>
>                 Key: JBAS-3580
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3580
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> testDummyLast - Error
> No durable subscription found for subscription: test
> javax.jms.InvalidDestinationException: No durable subscription found for subscription: test
> 	at org.jboss.mq.sm.AbstractStateManager.getDurableTopic(AbstractStateManager.java:164)
> 	at org.jboss.mq.server.JMSDestinationManager.getDurableTopic(JMSDestinationManager.java:777)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.getDurableTopic(JMSServerInterceptorSupport.java:181)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:207)
> 	at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:548)
> 	at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:162)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:214)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 13:59:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-536) The
 CallbackServer cannot
 be contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30777263.1157133584119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Ovidiu Feodorov updated JBMESSAGING-536:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10316556.1157133584299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=all ]

Ovidiu Feodorov updated JBMESSAGING-528:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20584258.1157133584557.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=all ]

Ovidiu Feodorov updated JBMESSAGING-499:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:45 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14089135.1157133585200.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov updated JBMESSAGING-525:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:45 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <20586228.1157133585411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov updated JBMESSAGING-432:
----------------------------------------

    Assignee: Clebert Suconic  (was: Tim Fox)

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 13:59:45 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 13:59:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-526) JMSRedelivered
 flag not correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19584363.1157133585588.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Ovidiu Feodorov updated JBMESSAGING-526:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:07:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 14:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21037655.1157134063909.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3600?page=comments#action_12342613 ] 
            
Brian Stansberry commented on JBAS-3600:
----------------------------------------

The serialVersionUID probably is computed differently.  From the java.io.Serializable javadoc:

"However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, ...."

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:11:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
Message-ID: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>

6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
-----------------------------------------------------------------------------------

                 Key: JBAS-3603
                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JCA service, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Weston Price
             Fix For: JBossAS-4.0.5.GA


All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with

Transaction already active, cannot nest transactions.
javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
	at org.jboss.tm.TxManager.begin(TxManager.java:209)
	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)

OR

Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
	... 16 more


-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:15:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6741376.1157134543842.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3600?page=comments#action_12342614 ] 
            
Dimitris Andreadis commented on JBAS-3600:
------------------------------------------

Cool. I had thought the algorigthm was standard more or less. I guess we need to exclude those classes from the test OR store a different set of GUIDs per tested JVM.

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:21:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3605) test failures
 org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase
 (jrockit)
Message-ID: <9882655.1157134903814.JavaMail.jira@cloud.prod.atl2.jboss.com>

test failures org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase (jrockit)
---------------------------------------------------------------------------------------------------

                 Key: JBAS-3605
                 URL: http://jira.jboss.com/jira/browse/JBAS-3605
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testGetCustom Failure expected:<InitialValue> but was:<changed>
junit.framework.ComparisonFailure: expected:<InitialValue> but was:<changed>
	at org.jboss.test.jmx.test.JMXInvokerUnitTestCase.testGetCustom(JMXInvokerUnitTestCase.java:85)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:35:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:35:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3606) failed
 org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
Message-ID: <4834417.1157135743871.JavaMail.jira@cloud.prod.atl2.jboss.com>

failed org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
----------------------------------------------------------------

                 Key: JBAS-3606
                 URL: http://jira.jboss.com/jira/browse/JBAS-3606
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


testSecureHttpInvokerFailure Failure
Should not have been able to lookup(jmx)
junit.framework.AssertionFailedError: Should not have been able to lookup(jmx)
	at org.jboss.test.naming.test.SecurityUnitTestCase.testSecureHttpInvokerFailure(SecurityUnitTestCase.java:77)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:37:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3607) failing
 org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
Message-ID: <24350644.1157135863866.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
-------------------------------------------------------------------

                 Key: JBAS-3607
                 URL: http://jira.jboss.com/jira/browse/JBAS-3607
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: EJB2, Test Suite
            Reporter: Dimitris Andreadis
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA


testEjbRemoveNotCalledForEveryCall Failure
createCounter expected:<1> but was:<0>
junit.framework.AssertionFailedError: createCounter expected:<1> but was:<0>
	at org.jboss.test.session.test.EjbRemoveUnitTestCase.testEjbRemoveNotCalledForEveryCall(EjbRemoveUnitTestCase.java:96)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:39:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3608) 2 failing tests
 org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
Message-ID: <3989808.1157135983973.JavaMail.jira@cloud.prod.atl2.jboss.com>

2 failing tests org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
-------------------------------------------------------------------------

                 Key: JBAS-3608
                 URL: http://jira.jboss.com/jira/browse/JBAS-3608
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite, Web Services
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


testHandlerFlowServerReturn Failure
testHandlerFlowAllPass Failure

Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
junit.framework.AssertionFailedError: Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.assertHandlerProtocol(HandlerFlowTestCase.java:140)
	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.testHandlerFlowServerReturn(HandlerFlowTestCase.java:134)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:39:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:39:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3609) failing
 org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
Message-ID: <23815383.1157135984122.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
-----------------------------------------------------------------

                 Key: JBAS-3609
                 URL: http://jira.jboss.com/jira/browse/JBAS-3609
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite, Web Services
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


testGetVersion Failure
expected:<Version-1.0> but was:<null>
junit.framework.ComparisonFailure: expected:<Version-1.0> but was:<null>
	at org.jboss.test.webservice.jbws70.JBWS70TestCase.testGetVersion(JBWS70TestCase.java:74)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:17:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3604) 2 failed tests -
 org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
Message-ID: <19803940.1157134663902.JavaMail.jira@cloud.prod.atl2.jboss.com>

2 failed tests - org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
---------------------------------------------------------------------------

                 Key: JBAS-3604
                 URL: http://jira.jboss.com/jira/browse/JBAS-3604
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testPersistentJndiXMBean Error Hello not bound
javax.naming.NameNotFoundException: Hello not bound
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
	at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
	at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
	at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
	at org.jboss.naming.NamingService.invoke(NamingService.java:354)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.test.jmx.interceptors.JNDIPersistence.invoke(JNDIPersistence.java:114)
	at org.jboss.test.jmx.interceptors.JNDISecurity.invoke(JNDISecurity.java:130)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
	at $Proxy1.lookup(Ljavax.naming.Name;)Ljava.lang.Object;(Unknown Source)
	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testPersistentJndiXMBean(DeployXMBeanUnitTestCase.java:520)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)

 testSecuredJndiXMBean Failure Was able to invoke secretEcho
junit.framework.AssertionFailedError: Was able to invoke secretEcho
	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testSecuredJndiXMBean(DeployXMBeanUnitTestCase.java:459)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Fri Sep  1 14:53:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 14:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3610) failing
 org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl)
 (jrockit)
Message-ID: <768700.1157136823860.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl) (jrockit)
-------------------------------------------------------------------------------------------------

                 Key: JBAS-3610
                 URL: http://jira.jboss.com/jira/browse/JBAS-3610
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite, Web Services
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


testWithTransportOptions Error

Call invocation failed: Could not transmit message; nested exception is: javax.xml.soap.SOAPException: Could not transmit message
java.rmi.RemoteException: Call invocation failed: Could not transmit message; nested exception is: 
	javax.xml.soap.SOAPException: Could not transmit message
	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:718)
	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: javax.xml.soap.SOAPException: Could not transmit message
	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:204)
	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
	... 23 more
Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
	at org.jboss.remoting.Client.invoke(Client.java:525)
	at org.jboss.remoting.Client.invoke(Client.java:488)
	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(BLjava.lang.Throwable;Ljava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(BLjava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush()V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_bc;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.j()V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_ba;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(BI)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j()V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Z)V(DashoA12275:???)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake()V(DashoA12275:???)
	at sun.net.www.protocol.https.HttpsClient.afterConnect()V(DashoA12275:???)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect()V(DashoA12275:???)
	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:569)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream()Ljava.io.OutputStream;(DashoA12275:???)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:163)
	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
	at org.jboss.remoting.Client.invoke(Client.java:525)
	at org.jboss.remoting.Client.invoke(Client.java:488)
	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 14:59:44 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 1 Sep 2006 14:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
In-Reply-To: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6449272.1157137184093.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3603?page=comments#action_12342615 ] 
            
Weston Price commented on JBAS-3603:
------------------------------------

I am assuing JRockit 1.4. This works fine for me on Windows. What platform are you testing on? 



> 6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-3603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with
> Transaction already active, cannot nest transactions.
> javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
> 	at org.jboss.tm.TxManager.begin(TxManager.java:209)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)
> OR
> Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
> 	... 16 more

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:01:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3611) Get the
 jboss-4.0-testsuite-sun-1.5 passing
Message-ID: <20914255.1157137303968.JavaMail.jira@cloud.prod.atl2.jboss.com>

Get the jboss-4.0-testsuite-sun-1.5 passing
-------------------------------------------

                 Key: JBAS-3611
                 URL: http://jira.jboss.com/jira/browse/JBAS-3611
             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 for sun jdk1.5 test run failures

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:01:44 2006
From: jira-events at jboss.com (G?bor Lipt?k (JIRA))
Date: Fri, 1 Sep 2006 15:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-444) patch to support
 Notes attribute on decision table Package
In-Reply-To: <9769524.1156268351914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8446581.1157137304276.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-444?page=comments#action_12342616 ] 
            
G?bor Lipt?k commented on JBRULES-444:
--------------------------------------

This would make the Notes field (at the package level top of the spreadsheet), injected as a comment at the package level of the generated rules. You could run the patched code against several of the example spreadsheets provided to see it in action.

> patch to support Notes attribute on decision table Package
> ----------------------------------------------------------
>
>                 Key: JBRULES-444
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-444
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Mark Proctor
>            Priority: Optional
>             Fix For: 3.0.4
>
>         Attachments: jboss_rules_decisiontable_package_notes.diff
>
>
> patch attached

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:03:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3612) failing
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
Message-ID: <23206066.1157137423945.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
----------------------------------------------------------------------

                 Key: JBAS-3612
                 URL: http://jira.jboss.com/jira/browse/JBAS-3612
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


test402Compatibility Failure
Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
org.jboss.console.manager.PluginManager$1,
org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
org.jboss.console.plugins.helpers.BasePluginWrapper,
org.jboss.console.plugins.helpers.servlet.TabTag,
org.jboss.console.remote.InvokerServlet,
org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
org.jboss.invocation.jrmp.server.JRMPInvoker,
org.jboss.proxy.ClientContainerEx,
org.jboss.proxy.ejb.DynamicIIOPStub,
org.jboss.proxy.ejb.HomeHandleImplIIOP,
org.jboss.tm.iiop._CoordinatorExtStub,
org.jboss.tm.iiop._TransactionFactoryExtStub,
org.jboss.tm.iiop._TransactionServiceStub
	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

 test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
org.jboss.aspects.versioned.StateManager,
org.jboss.console.manager.PluginManager$1,
org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
org.jboss.console.plugins.helpers.BasePluginWrapper,
org.jboss.console.plugins.helpers.servlet.TabTag,
org.jboss.console.remote.InvokerServlet,
org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
org.jboss.invocation.jrmp.server.JRMPInvoker,
org.jboss.monitor.alarm.AlarmNotification,
org.jboss.monitor.alarm.AlarmTableNotification,
org.jboss.proxy.ejb.DynamicIIOPStub,
org.jboss.proxy.ejb.HomeHandleImplIIOP,
org.jboss.tm.iiop._CoordinatorExtStub,
org.jboss.tm.iiop._TransactionFactoryExtStub,
org.jboss.tm.iiop._TransactionServiceStub

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:03:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:03:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3612) failing
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <23206066.1157137423945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <481967.1157137424093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3612?page=all ]

Dimitris Andreadis updated JBAS-3612:
-------------------------------------

    Environment: 
Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


> failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> ----------------------------------------------------------------------
>
>                 Key: JBAS-3612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3612
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> test402Compatibility Failure
> Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.proxy.ClientContainerEx,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
> org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.monitor.alarm.AlarmNotification,
> org.jboss.monitor.alarm.AlarmTableNotification,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:05:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:05:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3613) failing test in
 org.jboss.test.iiop.test.ParameterPassingStressTestCase
Message-ID: <18562400.1157137544244.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase
-----------------------------------------------------------------------

                 Key: JBAS-3613
                 URL: http://jira.jboss.com/jira/browse/JBAS-3613
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: IIOP service, Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Francisco Reverbel
             Fix For: JBossAS-4.0.5.GA


test_getException Error

Invalid indirection to offset 1704
java.io.IOException: Invalid indirection to offset 1704
	at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.read_Array(ValueHandlerImpl.java:756)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:325)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:1989)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2213)
	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2310)
	at org.jacorb.orb.Any.read_value(Any.java:816)
	at org.jacorb.orb.CDRInputStream.read_any(CDRInputStream.java:673)
	at com.sun.corba.se.impl.javax.rmi.CORBA.Util.readAny(Util.java:401)
	at javax.rmi.CORBA.Util.readAny(Util.java:92)
	at org.jboss.iiop.rmi.marshal.CDRStream$ObjectReader.read(CDRStream.java:618)
	at org.jboss.iiop.rmi.marshal.strategy.StubStrategy.readRetval(StubStrategy.java:226)
	at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:128)
	at org.jboss.test.iiop.interfaces._StatelessSession_Stub.getException(Unknown Source)
	at org.jboss.test.iiop.test.ParameterPassingStressTestCase.test_getException(ParameterPassingStressTestCase.java:355)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:05:45 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:05:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3614) failing
 org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
Message-ID: <5797013.1157137545169.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
-----------------------------------------------------------------------

                 Key: JBAS-3614
                 URL: http://jira.jboss.com/jira/browse/JBAS-3614
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA


testRMMResourceImplementsMBean Failure

testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
junit.framework.AssertionFailedError: testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
	at org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase.testRMMResourceImplementsMBean(ModelMBeanTestCase.java:150)
 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:07:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3615) failing test in
 org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
Message-ID: <10850104.1157137663981.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing test in org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
------------------------------------------------------------------------------

                 Key: JBAS-3615
                 URL: http://jira.jboss.com/jira/browse/JBAS-3615
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMX, Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testMalformed Failure

invalid object name: domain:=,foo=bar
junit.framework.AssertionFailedError: invalid object name: domain:=,foo=bar
	at org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase$FullNameTEST.testMalformed(MalformedTestCase.java:152)
 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:09:44 2006
From: jira-events at jboss.com (G?bor Lipt?k (JIRA))
Date: Fri, 1 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-447) correct
 NullPointer when processing PRIORITY rule tag
In-Reply-To: <21683851.1156360189213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6496865.1157137784034.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-447?page=all ]

G?bor Lipt?k updated JBRULES-447:
---------------------------------

    Attachment: PriorityTest.xls

NullPointer with PRIORITY column

> correct NullPointer when processing PRIORITY rule tag
> -----------------------------------------------------
>
>                 Key: JBRULES-447
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-447
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Michael Neale
>         Attachments: jboss_rules_priority.diff, PriorityTest.xls
>
>
> diff attached. I'm not sure if using LshBuilder is the correct thing to do ...

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:09:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3616) failing test
 org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
Message-ID: <29398985.1157137784152.JavaMail.jira@cloud.prod.atl2.jboss.com>

failing test org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
-----------------------------------------------------------

                 Key: JBAS-3616
                 URL: http://jira.jboss.com/jira/browse/JBAS-3616
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testMBeanInfoMarshalling Failure

Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
	at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)

 

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:09:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 1 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1014)
 NavigationPortlet enhancements
In-Reply-To: <28936719.1157040861641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21297348.1157137784328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1014?page=all ]

Roy Russo resolved JBPORTAL-1014.
---------------------------------

    Fix Version/s: 2.6.Alpha1
       Resolution: Done

moving submenu to its own task, as it depends on the new theme.

> NavigationPortlet enhancements
> ------------------------------
>
>                 Key: JBPORTAL-1014
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1014
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> 1. Add explicit ordering support
> 2. Add localization support
> 3. Investigate feasibility of adding submenu support for subpage listing.
> All configuration options should be made available in the portlet.xml and overriden as preferences in the instances.xml.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:11:43 2006
From: jira-events at jboss.com (G?bor Lipt?k (JIRA))
Date: Fri, 1 Sep 2006 15:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-447) correct
 NullPointer when processing PRIORITY rule tag
In-Reply-To: <21683851.1156360189213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12308222.1157137903927.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-447?page=comments#action_12342620 ] 
            
G?bor Lipt?k commented on JBRULES-447:
--------------------------------------

Attached an example XLS. Incidentally you could also use this as an example for

http://jira.jboss.com/jira/browse/JBRULES-444

Thanks

> correct NullPointer when processing PRIORITY rule tag
> -----------------------------------------------------
>
>                 Key: JBRULES-447
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-447
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Michael Neale
>         Attachments: jboss_rules_priority.diff, PriorityTest.xls
>
>
> diff attached. I'm not sure if using LshBuilder is the correct thing to do ...

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:11:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:11:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3617) 3 failing tests in
 org.jboss.test.util.test.PropertyEditorsUnitTestCase
Message-ID: <15495472.1157137904044.JavaMail.jira@cloud.prod.atl2.jboss.com>

3 failing tests in org.jboss.test.util.test.PropertyEditorsUnitTestCase
-----------------------------------------------------------------------

                 Key: JBAS-3617
                 URL: http://jira.jboss.com/jira/browse/JBAS-3617
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.5.0_05 
Java Vendor Sun Microsystems Inc. 
Java VM Name Java HotSpot(TM) Server VM 
Java VM Version 1.5.0_05-b05 
Java VM Info mixed mode 
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testEditorSearchPath Failure
Found org.jboss.util.propertyeditor in search path
junit.framework.AssertionFailedError: Found org.jboss.util.propertyeditor in search path
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testEditorSearchPath(PropertyEditorsUnitTestCase.java:127)


testJavaLangEditors Failure
Found property editor for: class java.lang.Boolean
junit.framework.AssertionFailedError: Found property editor for: class java.lang.Boolean
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJavaLangEditors(PropertyEditorsUnitTestCase.java:188)

testJBossEditors Failure
Found property editor for: class javax.management.ObjectName
junit.framework.AssertionFailedError: Found property editor for: class javax.management.ObjectName
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJBossEditors(PropertyEditorsUnitTestCase.java:306)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:15:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 1 Sep 2006 15:15:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
In-Reply-To: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7576079.1157138144133.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3603?page=all ]

Dimitris Andreadis updated JBAS-3603:
-------------------------------------

    Environment: 
Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


> 6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-3603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with
> Transaction already active, cannot nest transactions.
> javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
> 	at org.jboss.tm.TxManager.begin(TxManager.java:209)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)
> OR
> Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
> 	... 16 more

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:15:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 1 Sep 2006 15:15:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1017) Submenu support
 in NavigationPortlet
Message-ID: <8700605.1157138144292.JavaMail.jira@cloud.prod.atl2.jboss.com>

Submenu support in NavigationPortlet
------------------------------------

                 Key: JBPORTAL-1017
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1017
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo




-- 
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

        


From jira-events at jboss.com  Fri Sep  1 15:15:44 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Fri, 1 Sep 2006 15:15:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-678) RemoteBinding
 annotation doesn't use the default client binding of the remoting
In-Reply-To: <8002416.1154618891359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20987352.1157138144655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-678?page=comments#action_12342621 ] 
            
Bill Burke commented on EJBTHREE-678:
-------------------------------------

Make @RemoteBinding.clientBindUrl default to "" and we'll check for that.

> RemoteBinding annotation doesn't use the default client binding of the remoting
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-678
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. 
> When the jboss remoting service is not configured  using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. 
> The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value).
> I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration.
> The following fixes the issue using the first described approach:
> org.jboss.ejb3.stateless.ProxyDeployer
> public void initializeRemoteBindingMetadata()
>    {
>       remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class);
>       if (remoteBindings == null)
>   ...
>       }
>          else
>          {
>        	 // defaultClientBinding is more accurate that the constant in RemoteBinding 
>              if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) {
>                  binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory());
>              }
>             RemoteBinding[] list = {binding};
>             remoteBindings = new RemoteBindingsImpl(list);
>             advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings);
>          }
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 16:01:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 1 Sep 2006 16:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1900) Clustered webapp
 shouldn't require ClusteredSingleSignOn
Message-ID: <14638054.1157140904035.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1900?page=all ]

Brian Stansberry updated JBAS-1900:
-----------------------------------

                   Summary: Clustered webapp shouldn't require ClusteredSingleSignOn  (was: Clustered webapp shouldn't require ClusteredSingleSignon?)
    Workaround Description: I haven't tested this, so buyer beware. The request notes that using ClusteredSSO is not an option due to different sets of users for different webapps. Set the "requireReauthentication" attribute in the ClusteredSingleSignOnValve to "true".  Each request will then be reauthenticated by the security layer, which should prevent users from one set accessing resources meant for another set.
                Workaround: [Workaround Exists]

Suggested workaround added.

> Clustered webapp shouldn't require ClusteredSingleSignOn
> --------------------------------------------------------
>
>                 Key: JBAS-1900
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1900
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Security
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Stan Silvert
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> A customer had three webapps.  The set of users for each webapp is different.  So, they don't want single signon behavior.  They do want HttpSessionReplication to take care of the credentials so that the user doesn't need to sign on when redirected to another server.  It was found that we needed to enable clustered single signon to get this to work.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 16:13:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 1 Sep 2006 16:13:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-695) support
 properties service in ejb3
Message-ID: <18560791.1157141623768.JavaMail.jira@cloud.prod.atl2.jboss.com>

support properties service in ejb3
----------------------------------

                 Key: EJBTHREE-695
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-695
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: William DeCoste
         Assigned To: William DeCoste
             Fix For: EJB 3.0 RC9 - 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

        


From jira-events at jboss.com  Fri Sep  1 17:07:43 2006
From: jira-events at jboss.com (Alex Pinkin (JIRA))
Date: Fri, 1 Sep 2006 17:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3618) repository-zip
 target in
 build-release.xml doesn't consistently overwrite default config with all
Message-ID: <18718633.1157144863997.JavaMail.jira@cloud.prod.atl2.jboss.com>

repository-zip target in build-release.xml doesn't consistently overwrite default config with all
-------------------------------------------------------------------------------------------------

                 Key: JBAS-3618
                 URL: http://jira.jboss.com/jira/browse/JBAS-3618
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Alex Pinkin


   <target name="repository-zip"
     description="Create a canonical binaries for the repository">
     <mkdir dir="${version}/repository" />
     <echo message="jboss.dist=${jboss.dist}" />
     <!-- Create a unified server/lib directory -->
     <copy todir="${jboss.dist}/server/lib">
       <fileset dir="${jboss.dist}/server/minimal/lib" />
       <fileset dir="${jboss.dist}/server/default/lib" />
       <fileset dir="${jboss.dist}/server/all/lib" />
       <!-- Include the prematurely added quartz stuff for ejb3 config -->
       <fileset dir="${jboss.thirdparty}/quartz/lib" />
     </copy>
     <!-- Create a unified server/deploy directory -->
     <copy todir="${jboss.dist}/server/deploy">
       <fileset dir="${jboss.dist}/server/default/deploy" />
       <fileset dir="${jboss.dist}/server/all/deploy">
         <exclude name="jms/**" />
       </fileset>
       <!-- Include the prematurely added quartz stuff for ejb3 config -->
       <fileset dir="${jboss.cvs.dir}/connector/output/lib">
         <include name="quartz-ra.rar" />
       </fileset>
     </copy>
     <copy todir="${jboss.dist}/server/deploy-ha">
       <fileset dir="${jboss.dist}/server/all">
         <include name="deploy/jms/**" />
         <include name="deploy-hasingleton/**" />
         <include name="farm/**" />
       </fileset>
     </copy>

Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps.

There is overwrite=true attribute which need to be added to force overwrites.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 17:09:44 2006
From: jira-events at jboss.com (Alex Pinkin (JIRA))
Date: Fri, 1 Sep 2006 17:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3618) repository-zip
 target in
 build-release.xml doesn't consistently overwrite default config with all
In-Reply-To: <18718633.1157144863997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12075845.1157144984014.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3618?page=all ]

Alex Pinkin updated JBAS-3618:
------------------------------

          Component/s: Build System
        Fix Version/s: JBossAS-4.0.5.GA
    Affects Version/s: JBossAS-4.0.4.GA

> repository-zip target in build-release.xml doesn't consistently overwrite default config with all
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3618
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3618
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Alex Pinkin
>             Fix For: JBossAS-4.0.5.GA
>
>
>    <target name="repository-zip"
>      description="Create a canonical binaries for the repository">
>      <mkdir dir="${version}/repository" />
>      <echo message="jboss.dist=${jboss.dist}" />
>      <!-- Create a unified server/lib directory -->
>      <copy todir="${jboss.dist}/server/lib">
>        <fileset dir="${jboss.dist}/server/minimal/lib" />
>        <fileset dir="${jboss.dist}/server/default/lib" />
>        <fileset dir="${jboss.dist}/server/all/lib" />
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.thirdparty}/quartz/lib" />
>      </copy>
>      <!-- Create a unified server/deploy directory -->
>      <copy todir="${jboss.dist}/server/deploy">
>        <fileset dir="${jboss.dist}/server/default/deploy" />
>        <fileset dir="${jboss.dist}/server/all/deploy">
>          <exclude name="jms/**" />
>        </fileset>
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.cvs.dir}/connector/output/lib">
>          <include name="quartz-ra.rar" />
>        </fileset>
>      </copy>
>      <copy todir="${jboss.dist}/server/deploy-ha">
>        <fileset dir="${jboss.dist}/server/all">
>          <include name="deploy/jms/**" />
>          <include name="deploy-hasingleton/**" />
>          <include name="farm/**" />
>        </fileset>
>      </copy>
> Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps.
> There is overwrite=true attribute which need to be added to force overwrites.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 18:27:44 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Fri, 1 Sep 2006 18:27:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <4964465.1157149664076.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment: new_splash_left_aligned.jpg

Hey James.. the new splash screen is looking great.. I got around to integrating it along with your updated progress bar/message placement and I had a few comments/suggestions:

1) The BMP you sent didn't have any shadowing effects around the border, so it kind of "disappears" into the background if you're looking at something that is white (for example a web page in a browser or similar). Would you mind re-creating the splash with some kind of fade-out or border affect similar to what you showed in your original proposal?

2) Apparently the "loading" message text in eclipse is left-aligned only, meaning it doesn't flush over to the right side of the progress bar like in the mockup you sent. Do you think it would ruin the flow of the new splash screen if we changed the JBoss logo over to the right side, and put the progress message on the left? I'm attaching a screenshot of what the current splash looks like w/ the left aligned text.

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:05:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 1 Sep 2006 20:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5465193.1157155543852.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=comments#action_12342657 ] 
            
Tim Fox commented on JBMESSAGING-505:
-------------------------------------

The current solution to this makes a copy of the entire receivers list for every message that is sent through the router.

This is likely to have an adverse effect on performance, especially when there are many receivers.

A better solution should be found to the race condition that does not involve cloning the list.

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:05:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 1 Sep 2006 20:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25719159.1157155543965.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Tim Fox reopened JBMESSAGING-505:
---------------------------------

             

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:07:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 1 Sep 2006 20:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1971670.1157155663868.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Tim Fox updated JBMESSAGING-505:
--------------------------------

    Fix Version/s: 1.0.1.GA
                       (was: 1.0.1.CR5)

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:41:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 1 Sep 2006 20:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-678) RemoteBinding
 annotation doesn't use the default client binding of the remoting
In-Reply-To: <8002416.1154618891359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26123642.1157157704259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-678?page=all ]

William DeCoste closed EJBTHREE-678.
------------------------------------

    Resolution: Done

> RemoteBinding annotation doesn't use the default client binding of the remoting
> -------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-678
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-678
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> The org.jboss.annotation.ejb.RemoteBinding annotation configures the jndi binding, interceptor stack, the client bind url and the RemoteProxyFactroy. 
> When the jboss remoting service is not configured  using the url socket://0.0.0.0:3873 (not listening on the default port or using ssl), the programmer has to specify the the url when he wants to bind the bean to a different jndi context. 
> The deployment has to be deployed into different JBoss instances (pre-production, production,...) with different ports, the deployment has to be rebuilt (different jboss.xml) or even recompiled (with different annotation value).
> I propose that the default "socket://0.0.0.0:3873" means the default of the remoting configuration or even better set the default to "" in the annotation which would be interpreted as the default remoting configuration.
> The following fixes the issue using the first described approach:
> org.jboss.ejb3.stateless.ProxyDeployer
> public void initializeRemoteBindingMetadata()
>    {
>       remoteBindings = (RemoteBindings) advisor.resolveAnnotation(RemoteBindings.class);
>       if (remoteBindings == null)
>   ...
>       }
>          else
>          {
>        	 // defaultClientBinding is more accurate that the constant in RemoteBinding 
>              if ("socket://0.0.0.0:3873".equals(binding.clientBindUrl())) {
>                  binding = new RemoteBindingImpl(binding.jndiBinding(), binding.interceptorStack(), defaultClientBinding, binding.factory());
>              }
>             RemoteBinding[] list = {binding};
>             remoteBindings = new RemoteBindingsImpl(list);
>             advisor.getAnnotations().addClassAnnotation(RemoteBindings.class, remoteBindings);
>          }
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:47:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 20:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21391259.1157158064169.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=comments#action_12342658 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-505:
---------------------------------------------

Good show case for "measure first and optimize based on measurements"

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 20:47:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 1 Sep 2006 20:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6520371.1157158064308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Ovidiu Feodorov updated JBMESSAGING-505:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.GA)

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Fri Sep  1 21:51:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 1 Sep 2006 21:51:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-677) EJB3 deployments
 should be bound with rebind instead of bind
In-Reply-To: <7679261.1154618051633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16129049.1157161904249.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-677?page=all ]

William DeCoste closed EJBTHREE-677.
------------------------------------

    Resolution: Done

> EJB3 deployments should be bound with rebind instead of bind
> ------------------------------------------------------------
>
>                 Key: EJBTHREE-677
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-677
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Using bind instead of rebind may cause trouble when the JNDI implementation is persistent (e.g. in an ldap directory) because deploying a previously crashed application will fail. 
> I know that the current situation can also be seen as a feature because the developer cannot deploy two different beans with the same jndi name but this has in my opinion a lesser priority. Further the ejb 2.x stack uses rebind too.
> The request http://jira.jboss.com/jira/browse/EJBTHREE-51 describtes to use Util.rebind()  but in fisheye I saw Util.bind().

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 09:49:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 09:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-296) List and document
 system properties used in JGroups
Message-ID: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>

List and document system properties used in JGroups
---------------------------------------------------

                 Key: JGRP-296
                 URL: http://jira.jboss.com/jira/browse/JGRP-296
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.4


- bind.address
- ignore.bind.address
- jboss.tcpping.initial_hosts
- jboss.partition.udpPort
- jboss.partition.udpGroup
- jboss.mcast.ip.ttl

#1 Collect all system properties used by JGroups
#2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
#3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 10:01:44 2006
From: jira-events at jboss.com (Denis Peyrusaubes (JIRA))
Date: Sat, 2 Sep 2006 10:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-696) Not active
 transaction in a slsb
Message-ID: <14938454.1157205704015.JavaMail.jira@cloud.prod.atl2.jboss.com>

Not active transaction in a slsb
--------------------------------

                 Key: EJBTHREE-696
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-696
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC8 - FD
         Environment: jboss-4.0.4.GA
            Reporter: Denis Peyrusaubes
            Priority: Minor


Calling the setRollBackOnly method in a method of SLSB marked with Required attribute throws a "org.jboss.util.NestedSQLException: Transaction is not active".


-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:01:47 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:01:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-147) Deadlock in
 AsynchViewChangeaHandler
Message-ID: <5073888.1157209307793.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock in AsynchViewChangeaHandler
------------------------------------

                 Key: JBCLUSTER-147
                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-147
             Project: JBoss Clustering
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: JBoss-4.0 (branch)
            Reporter: Bela Ban
         Assigned To: Brian Stansberry


Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads


Name: main
State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
Total blocked: 6  Total waited: 17

Stack trace: 
at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)




Name: AsynchViewChangeHandler Thread
State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
Total blocked: 1  Total waited: 1
 
Stack trace: 
at org.jboss.system.ServiceController.create(ServiceController.java:286)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy46.create(Unknown Source)
at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy47.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
at java.lang.Thread.run(Thread.java:595)


-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:33:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-2) Memory based flow
	control
Message-ID: <12577848.1157211223843.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-2?page=comments#action_12342685 ] 
            
Bela Ban commented on JGRP-2:
-----------------------------

Memory monitoring could be done by (JDK 5 only) java.lang.management.MemoryMXBean, with notifications.

> Memory based flow control
> -------------------------
>
>                 Key: JGRP-2
>                 URL: http://jira.jboss.com/jira/browse/JGRP-2
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.x
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Memory and retransmission based flow control protocol. Should be much faster than the current FC
> on a fast network, we can still run out of memory because received_msgs/delivered_msgs becomes very big.
>   Instead of basing FC on the speed of the network, we should also take the number of messages processed
>   (a.k.a delivered_msgs/received_msgs) into account, and only send credits when that number falls below a
>   certain threshold. First: look at the number of received/delivered msgs in the perf test !
>   --> Look into memory-based FC: criteria for sending credits are
>       - available free memory
>       - outstanding retransmission requests (sender sends with each message number of messages sent,
>         receiver keeps track of how many messages received, if diff is > threshold --> pause)
>       - [optional] latency

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:41:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:41:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-297) Use deadlock
 detection (JDK 5) to
 find deadlocks in stress tests or during regular operation
Message-ID: <2972305.1157211703949.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use deadlock detection (JDK 5) to find deadlocks in stress tests or during regular operation
--------------------------------------------------------------------------------------------

                 Key: JGRP-297
                 URL: http://jira.jboss.com/jira/browse/JGRP-297
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


The java.lang.management.ThreadMXBean has a method to check for and (if found) enumerate deadlocked threads (only with simply synchronized locks, jav.util.concurrent locks currently not supported afaik).
This can be run every N seconds, and is useful in both stress testing and possibly also during operation.

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 11:41:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 2 Sep 2006 11:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-297) Use deadlock
 detection (JDK 5)
 to find deadlocks in stress tests or during regular operation
In-Reply-To: <2972305.1157211703949.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8860123.1157211704083.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-297?page=comments#action_12342686 ] 
            
Bela Ban commented on JGRP-297:
-------------------------------

Links: 
- java.lang.management package
- Heinz article: http://www.javaspecialists.co.za/archive/newsletter.do?issue=093&locale=en_US and http://www.javaspecialists.co.za/archive/newsletter.do?issue=093&locale=en_US

> Use deadlock detection (JDK 5) to find deadlocks in stress tests or during regular operation
> --------------------------------------------------------------------------------------------
>
>                 Key: JGRP-297
>                 URL: http://jira.jboss.com/jira/browse/JGRP-297
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.5
>
>
> The java.lang.management.ThreadMXBean has a method to check for and (if found) enumerate deadlocked threads (only with simply synchronized locks, jav.util.concurrent locks currently not supported afaik).
> This can be run every N seconds, and is useful in both stress testing and possibly also during operation.

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 16:59:44 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 16:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-435) Large integer
 values in
 decision tables are converted to scientific notation in DRL which cannot be
 parsed
In-Reply-To: <8098647.1155759034300.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21896878.1157230784097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-435?page=all ]

Mark Proctor updated JBRULES-435:
---------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Large integer values in decision tables are converted to scientific notation in DRL which cannot be parsed
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-435
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-435
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Drl Parser/Builder
>            Reporter: Volker Augustin
>         Assigned To: Michael Neale
>
> When a condition column in a decision table contains values like 25000000, this is compiled using the SpreadsheetCompiler into 2.5E7 in the DRL. However, the DRL parser/compiler cannot cope with this notation and exists with a unexpected token "E7" error 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

        


From jira-events at jboss.com  Sat Sep  2 17:03:43 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 17:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-118) Map generated
 .java compilation errors to  drl
Message-ID: <28553369.1157231024002.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-118?page=comments#action_12342695 ] 
            
Mark Proctor commented on JBRULES-118:
--------------------------------------

yup, but you just fixed that :)
Yes its not a nice solution, as runtime errors will still report the wrong line numbers - unless we "clone" errors replacing with correct filename and line numbers - but this can just get messy with stack traces etc. 
You are right that the whole solution is not that nice, but I can't think of any nicer way with execution of compiled code.

> Map generated .java  compilation errors to  drl
> -----------------------------------------------
>
>                 Key: JBRULES-118
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-118
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Bob McWhirter
>             Fix For: 3.1-m3
>
>
> We know the method name for each descr. If we move the params all onto  a  single line we can use indexof to fine the start of each descr' compiled  code. We can then use that  to find the offiset and map the error  to the descr.
> This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors).

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 17:03:44 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 17:03:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-118) Map generated .java
 compilation errors to  drl
Message-ID: <28620590.1157231024127.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-118?page=all ]

Mark Proctor updated JBRULES-118:
---------------------------------

    Assignee: Mark Proctor  (was: Bob McWhirter)

> Map generated .java  compilation errors to  drl
> -----------------------------------------------
>
>                 Key: JBRULES-118
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-118
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m3
>
>
> We know the method name for each descr. If we move the params all onto  a  single line we can use indexof to fine the start of each descr' compiled  code. We can then use that  to find the offiset and map the error  to the descr.
> This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors).

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 17:07:44 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 17:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-379) function with
 another drools
 function call won't compile (either with eclipse compiler or janino)
In-Reply-To: <13656185.1153782491575.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31652477.1157231264141.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-379?page=all ]

Mark Proctor closed JBRULES-379.
--------------------------------

    Fix Version/s: 3.1-m1
       Resolution: Done

FunctionBuilder now uses FunctionFixer.

> function with another drools function call won't compile (either with eclipse compiler or janino)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-379
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-379
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.1
>         Environment: Debian linux
> JDK 5
>            Reporter: Thierry R
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m1
>
>
> function with another drools function call won't compile (either with eclipse compiler or janino)
> with the error msg :
> "Function Compilation error "
> I wrote a DroolsHelper class to work around.

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 19:17:43 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 2 Sep 2006 19:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-118) Map generated .java
 compilation errors to  drl
Message-ID: <10465510.1157239063854.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-118?page=all ]

Mark Proctor closed JBRULES-118.
--------------------------------

    Resolution: Done

> Map generated .java  compilation errors to  drl
> -----------------------------------------------
>
>                 Key: JBRULES-118
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-118
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m3
>
>
> We know the method name for each descr. If we move the params all onto  a  single line we can use indexof to fine the start of each descr' compiled  code. We can then use that  to find the offiset and map the error  to the descr.
> This is complex as the error handling needs to be reworked. CompilationProblem objects should NOT be stuffed inside rule errors, but be seperate rule errors (hence can have multiple line errors).

-- 
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

        


From jira-events at jboss.com  Sat Sep  2 19:55:43 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Sat, 2 Sep 2006 19:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-211) update user guide to
 include new features
Message-ID: <24593365.1157241343825.JavaMail.jira@cloud.prod.atl2.jboss.com>

update user guide to include new features
-----------------------------------------

                 Key: BPEL-211
                 URL: http://jira.jboss.com/jira/browse/BPEL-211
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documents
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1 beta 2


-Describe the simplified deployment process
-Document time-driven activities

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 01:11:44 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Sun, 3 Sep 2006 01:11:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-589) Fix raw_socket
 performance tests.
In-Reply-To: <28580876.1156453129208.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15363683.1157260304057.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-589?page=comments#action_12342704 ] 
            
Ron Sigal commented on JBREM-589:
---------------------------------

One more change was necessary.  The various server threads get a port number for a callback server, but there was only one callbackServerPort variable, and the threads were stepping on each other.  callbackServerPort is now a ThreadLocal variable.

> Fix raw_socket performance tests.
> ---------------------------------
>
>                 Key: JBREM-589
>                 URL: http://jira.jboss.com/jira/browse/JBREM-589
>             Project: JBoss Remoting
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.0.0.GA (Boon)
>
>
> raw_socket performance tests throwing NullPointerException in SocketPerformanceClient.makeInvocation().

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 11:51:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 11:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3619) Deadlock in
 AsynchViewChangeHandler
Message-ID: <4494655.1157298703835.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock in AsynchViewChangeHandler
-----------------------------------

                 Key: JBAS-3619
                 URL: http://jira.jboss.com/jira/browse/JBAS-3619
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Critical
             Fix For: JBossAS-4.0.5.GA


Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads


Name: main
State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
Total blocked: 6 Total waited: 17

Stack trace:
at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy8.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:464)
at java.lang.Thread.run(Thread.java:595)




Name: AsynchViewChangeHandler Thread
State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
Total blocked: 1 Total waited: 1
 
Stack trace:
at org.jboss.system.ServiceController.create(ServiceController.java:286)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy46.create(Unknown Source)
at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy47.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
at java.lang.Thread.run(Thread.java:595) 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 11:53:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 11:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-147) Deadlock in
 AsynchViewChangeaHandler
In-Reply-To: <5073888.1157209307793.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5653068.1157298823893.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-147?page=all ]

Brian Stansberry resolved JBCLUSTER-147.
----------------------------------------

    Resolution: Duplicate Issue

I'll deal with this via JBAS-3619.

> Deadlock in AsynchViewChangeaHandler
> ------------------------------------
>
>                 Key: JBCLUSTER-147
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-147
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: JBoss-4.0 (branch)
>            Reporter: Bela Ban
>         Assigned To: Brian Stansberry
>
> Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads
> Name: main
> State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
> Total blocked: 6  Total waited: 17
> Stack trace: 
> at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
> at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
> at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> at org.jboss.Main.boot(Main.java:200)
> at org.jboss.Main$1.run(Main.java:464)
> at java.lang.Thread.run(Thread.java:595)
> Name: AsynchViewChangeHandler Thread
> State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
> Total blocked: 1  Total waited: 1
>  
> Stack trace: 
> at org.jboss.system.ServiceController.create(ServiceController.java:286)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy46.create(Unknown Source)
> at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
> at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
> at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
> at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy47.create(Unknown Source)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
> at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
> at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
> at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
> at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 12:57:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 12:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3619) Deadlock in
 AsynchViewChangeHandler
In-Reply-To: <4494655.1157298703835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30903956.1157302663798.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3619?page=all ]

Brian Stansberry closed JBAS-3619.
----------------------------------

    Resolution: Done

Problem was HAPartitionImpl was holding a lock on its membership listener ArrayList while iterating through it and notifying listeners of  a change event. It now only synchronizes to clone the listener list, and then iterates over the clone.

> Deadlock in AsynchViewChangeHandler
> -----------------------------------
>
>                 Key: JBAS-3619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3619
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Deadlock happened during the StressTester HTTP session replication stress test. Stress tester was run on 2 nodes, with 80 threads
> Name: main
> State: BLOCKED on java.util.ArrayList at 2ad631 owned by: AsynchViewChangeHandler Thread
> Total blocked: 6 Total waited: 17
> Stack trace:
> at org.jboss.ha.framework.server.HAPartitionImpl.registerMembershipListener(HAPartitionImpl.java:1006)
> at org.jboss.ha.framework.server.ClusterFileTransfer.<init>(ClusterFileTransfer.java:77)
> at org.jboss.ha.framework.server.FarmMemberService.startService(FarmMemberService.java:173)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy8.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> at org.jboss.Main.boot(Main.java:200)
> at org.jboss.Main$1.run(Main.java:464)
> at java.lang.Thread.run(Thread.java:595)
> Name: AsynchViewChangeHandler Thread
> State: BLOCKED on org.jboss.system.ServiceController at 16c25eb owned by: main
> Total blocked: 1 Total waited: 1
>  
> Stack trace:
> at org.jboss.system.ServiceController.create(ServiceController.java:286)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy46.create(Unknown Source)
> at org.jboss.web.AbstractWebContainer.create(AbstractWebContainer.java:445)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
> at org.jboss.ws.integration.jboss.DeployerInterceptor.create(DeployerInterceptor.java:74)
> at org.jboss.ws.integration.jboss.DeployerInterceptorJSE.create(DeployerInterceptorJSE.java:74)
> at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
> at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy47.create(Unknown Source)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.create(MainDeployer.java:959)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:247)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:845)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.purgeDeadMembers(DistributedReplicantManagerImpl.java:1008)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.membershipChanged(DistributedReplicantManagerImpl.java:376)
> at org.jboss.ha.framework.server.HAPartitionImpl.notifyListeners(HAPartitionImpl.java:1258)
> at org.jboss.ha.framework.server.HAPartitionImpl.processEvent(HAPartitionImpl.java:1137)
> at org.jboss.ha.framework.server.AsynchEventHandler.run(AsynchEventHandler.java:107)
> at java.lang.Thread.run(Thread.java:595) 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 13:37:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 13:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9355723.1157305063812.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-296?page=comments#action_12342709 ] 
            
Brian Stansberry commented on JGRP-296:
---------------------------------------

A couple others for MPING, which would want to use a different address/port from any UDP-based channel in the same JVM:

jgroups.mping.mcast_addr
jgroups.mping.mcast_port

Also, a transition from jboss.partition.udpGroup to jgroups.udp.mcast_addr can be done within the AS itself.  All new config files use  jgroups.udp.mcast_addr, but if the -u switch is set both system properties get set, so legacy config files still work.

> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 14:01:43 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Sun, 3 Sep 2006 14:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-502) Create a
 MSSQL persistence manager config
In-Reply-To: <29492968.1155039912398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <656738.1157306503830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-502?page=all ]

Luc Texier resolved JBMESSAGING-502.
------------------------------------

    Resolution: Done


a brand new pm called mssql-persistence-service.xml is not present in src\etc\server\default\deploy in Branch_1_0

I also updated the wiki pages. I created new sections and added pages to explain how to deploy the pm configuration
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessaging



> Create a MSSQL persistence manager config
> -----------------------------------------
>
>                 Key: JBMESSAGING-502
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-502
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Luc Texier
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 14:47:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Sun, 3 Sep 2006 14:47:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-695) support properties
 service in ejb3
In-Reply-To: <18560791.1157141623768.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4648267.1157309263841.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-695?page=all ]

William DeCoste closed EJBTHREE-695.
------------------------------------

    Resolution: Done

> support properties service in ejb3
> ----------------------------------
>
>                 Key: EJBTHREE-695
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-695
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - 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

        


From jira-events at jboss.com  Sun Sep  3 15:45:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 3 Sep 2006 15:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29740313.1157312743819.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-296?page=comments#action_12342714 ] 
            
Brian Stansberry commented on JGRP-296:
---------------------------------------

Also, I prefer what you did with things like jgroups.udp.mcast_addr rather than mcast.addr.  Easier to remember that way -- last element of property name matches the attribute name.  So a convention could be:

jgroups.<protocol name in lower case>.attribute_name

with the second element removed or replaced by something generic if the same system property is used in more than one protocol, e.g.

jgroups.bind_addr  (2nd element removed)

jgroups.mcast.ip_ttl  (2nd element is 'mcast' since the same value is used for both UDP and MPING)


> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 16:47:44 2006
From: jira-events at jboss.com (bugra uytun (JIRA))
Date: Sun, 3 Sep 2006 16:47:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
Message-ID: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>

hibernate reverse engineering does not set "schema" attribute in .hbm.xml
-------------------------------------------------------------------------

                 Key: JBIDE-359
                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
             Project: JBoss IDE
          Issue Type: Bug
          Components: Hibernate Tools
         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
            Reporter: bugra uytun
         Assigned To: Max Andersen


i set the schema in hibernate.cfg.xml with:

---
<property name="hibernate.default_schema">mySchema</property>
---

after reverse engineering the DB I get the .hbm.xml file

---
...
<hibernate-mapping>
    <class name="com.someclass" table="MY_TABLE">
...
---

notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:

---
org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
---


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 16:49:43 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Sun, 3 Sep 2006 16:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
In-Reply-To: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14135320.1157316583827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-359?page=all ]

Max Andersen closed JBIDE-359.
------------------------------

    Resolution: Rejected

if you don't what it to be the default schema then don't set it as the default schema.

> hibernate reverse engineering does not set "schema" attribute in .hbm.xml
> -------------------------------------------------------------------------
>
>                 Key: JBIDE-359
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>
> i set the schema in hibernate.cfg.xml with:
> ---
> <property name="hibernate.default_schema">mySchema</property>
> ---
> after reverse engineering the DB I get the .hbm.xml file
> ---
> ...
> <hibernate-mapping>
>     <class name="com.someclass" table="MY_TABLE">
> ...
> ---
> notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:
> ---
> org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
> ---

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 16:51:43 2006
From: jira-events at jboss.com (bugra uytun (JIRA))
Date: Sun, 3 Sep 2006 16:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-360) wrong spelling in
 Hibernate Code Generation window
Message-ID: <12128434.1157316703833.JavaMail.jira@cloud.prod.atl2.jboss.com>

wrong spelling in Hibernate Code Generation window
--------------------------------------------------

                 Key: JBIDE-360
                 URL: http://jira.jboss.com/jira/browse/JBIDE-360
             Project: JBoss IDE
          Issue Type: Bug
          Components: Hibernate Tools
         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
            Reporter: bugra uytun
         Assigned To: Max Andersen
            Priority: Trivial


wrong spelling in Hibernate Code Generation window => "Main" tab => "Dectect optimistic lock columns" checkbox.

instead of "Dectect" it should be "Detect"

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 17:59:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 17:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-710) Producer
	clustering support
Message-ID: <1463638.1157320783904.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-710?page=all ]

Julien Viet updated JBPORTAL-710:
---------------------------------

        Fix Version/s:     (was: 2.6 Final)
    Affects Version/s:     (was: 2.4 Final)

> Producer clustering support
> ---------------------------
>
>                 Key: JBPORTAL-710
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-710
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 17:59:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 17:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-264) Login module can
 create missing user
Message-ID: <30225836.1157320784075.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-264?page=all ]

Julien Viet updated JBPORTAL-264:
---------------------------------

    Assignee:     (was: Chris Laprun)

> Login module can create missing user
> ------------------------------------
>
>                 Key: JBPORTAL-264
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-264
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add an option to the ModelLoginModule in order that it creates anuser when it does not exist. This would obviously work in conjonction with another login module placed in front of it that would authenticate username/password. The communication between the two modules would be done by using password stacking.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:01:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32043186.1157320904096.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Julien Viet resolved JBPORTAL-964.
----------------------------------

    Resolution: Cannot Reproduce Bug

2.6 will feature a new theme so that issues cannot be resolved.

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>             Fix For: 2.6 Final
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:01:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-453) Implement
 producer URL writing
Message-ID: <2863190.1157320904259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-453?page=all ]

Julien Viet resolved JBPORTAL-453.
----------------------------------

    Resolution: Duplicate Issue

> Implement producer URL writing
> ------------------------------
>
>                 Key: JBPORTAL-453
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-453
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Polina Alber
>         Assigned To: Chris Laprun
>             Fix For: 2.6 Final
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:05:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-233) User metadata
Message-ID: <31754208.1157321143953.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-233?page=all ]

Julien Viet updated JBPORTAL-233:
---------------------------------

    Component/s: Identity
                     (was: Portal Core)

> User metadata
> -------------
>
>                 Key: JBPORTAL-233
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-233
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>
> The portal defines itw own way to manipulate user. The current interface definition is capable to manipulate users. In particular it is possible to use user properties in a dynamic way. However it is not possible to know what properties are supported. Therefore we need to add metadata to the module in order to know informations about the properties available and supported by the portal.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:05:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:05:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-264) Login module can
 create missing user
Message-ID: <31739921.1157321144126.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-264?page=all ]

Julien Viet updated JBPORTAL-264:
---------------------------------

    Component/s: Identity
                     (was: Portal Core)

> Login module can create missing user
> ------------------------------------
>
>                 Key: JBPORTAL-264
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-264
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add an option to the ModelLoginModule in order that it creates anuser when it does not exist. This would obviously work in conjonction with another login module placed in front of it that would authenticate username/password. The communication between the two modules would be done by using password stacking.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:05:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:05:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-464) LDAP
 implementation of UserModule and RoleModule
Message-ID: <8896631.1157321144349.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-464?page=all ]

Julien Viet updated JBPORTAL-464:
---------------------------------

    Component/s: Identity
                     (was: Portal Core)

> LDAP implementation of UserModule and RoleModule
> ------------------------------------------------
>
>                 Key: JBPORTAL-464
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-464
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.0 Final, 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6 Final
>
>         Attachments: MSADLoginModule.zip, org.zip
>
>   Original Estimate: 1 week
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPTL-18) JSR-168
Message-ID: <31089929.1157321267937.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-18?page=all ]

Julien Viet updated JBPTL-18:
-----------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> JSR-168
> -------
>
>                 Key: JBPTL-18
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-18
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> Finish the JSR-168 full impl. These features are not a problem for the compliance and are not widely used

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-677) Secure Portlet
	Modes
Message-ID: <8658435.1157321272534.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-677?page=all ]

Julien Viet updated JBPORTAL-677:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Secure Portlet Modes
> --------------------
>
>                 Key: JBPORTAL-677
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-677
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2 Branch
>            Reporter: Jouni Rajala
>             Fix For: 2.6.Alpha1
>
>
> Request for feature that allows me to secure portlet mode per User's Role. I need this to prevent anonymous and 'normal' users to customize portlets while allowing advanced users to enter into edit mode.
> For me this feature is blocker, because I can't deploy my application to JBoss portal if modes can't be secured.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-464) LDAP
 implementation of UserModule and RoleModule
Message-ID: <3942471.1157321272673.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-464?page=all ]

Julien Viet updated JBPORTAL-464:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> LDAP implementation of UserModule and RoleModule
> ------------------------------------------------
>
>                 Key: JBPORTAL-464
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-464
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.0 Final, 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>         Attachments: MSADLoginModule.zip, org.zip
>
>   Original Estimate: 1 week
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-835) Implement
 WSRPActionContext
 getContentLength, getReader and getInputStream correctly.
Message-ID: <12243695.1157321272783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-835?page=all ]

Julien Viet updated JBPORTAL-835:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Implement WSRPActionContext getContentLength, getReader and getInputStream correctly.
> -------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-835
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-835
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Right now throws UnsupportedOperationException since previous implementation was returning raw information from the SOAP request.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:52 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-896) JBoss Portal look
	and feel
Message-ID: <760757.1157321272930.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-896?page=all ]

Julien Viet updated JBPORTAL-896:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> JBoss Portal look and feel
> --------------------------
>
>                 Key: JBPORTAL-896
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-896
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Damon Sicore
>             Fix For: 2.6.Alpha1
>
>
> we need a (rather good and appealing) default look and feel composed
> - theme
> - icons
> - custom css styles : portlet and portal
> additonally we need 2 additional themes.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-730) "Copy" should
 copy the live revision
Message-ID: <29310339.1157321273089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-730?page=all ]

Julien Viet updated JBPORTAL-730:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> "Copy" should copy the live revision
> ------------------------------------
>
>                 Key: JBPORTAL-730
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-730
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.2 Branch
>            Reporter: Thomas Heute
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> The current "copy" feature using Jackrabbit Workspace.copy() seems to copy the latest revision and only that one.
> Jackrabbit implementation won't help here (since it should be faster to do it at this level)
> If we decide to copy a unique revision we should copy the Live version. (can be different from the latest)
> Now the question is: should we copy all revisions or only the live one ?

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-887) Portal UI
 usuability improvements
Message-ID: <22863300.1157321273265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-887?page=all ]

Julien Viet updated JBPORTAL-887:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portal UI usuability improvements
> ---------------------------------
>
>                 Key: JBPORTAL-887
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-887
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Branch
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Roy Russo
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> some stuff that can be improved in UI Usuability
> 1) In Admin Portlet when you add portlet instances to a page the list of them is not sorted anyway so it's hard to fine what you want. Plus possibly with many portlets it will be hard to handle it from drop down list

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-715) Consumer explicit
 property setting mechanism with GUI for property management
Message-ID: <28165776.1157321273424.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-715?page=all ]

Julien Viet updated JBPORTAL-715:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer explicit property setting mechanism with GUI for property management
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-715
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-715
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-808) Check WSRP type
 definition to check for non-nillable values
Message-ID: <15411931.1157321273553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-808?page=all ]

Julien Viet updated JBPORTAL-808:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Check WSRP type definition to check for non-nillable values
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-808
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-808
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 hours
>          Time Spent: 1 hour
>  Remaining Estimate: 3 hours
>
> JBoss WS stack creates default value for nillable WSDL elements. If no valid value is provided for a non-nillable element, this will cause an error about elements being out of sequence.
> Example:
> From wsrp_v1_types.xsd, a valid markup request conforms to the getMarkup element:
> registrationContext (nillable), portletContext, runtimeContext, userContext (nillable), markupParams.
> runtimeContext is non-nillable. If no valid runtimeContext is provided when creating the getMarkup object, the WS stack will not emit an element for runtimeContext whereas one will be for userContext (which is nillable), resulting in the WS complaining about userContext not being in the right position in the sequence.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-705) Consumer implicit
 cloning support
Message-ID: <6355517.1157321273748.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-705?page=all ]

Julien Viet updated JBPORTAL-705:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer implicit cloning support
> ---------------------------------
>
>                 Key: JBPORTAL-705
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-705
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:53 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-965) Localization
	Support bug
In-Reply-To: <15499109.1153473071330.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14510433.1157321273877.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-965?page=all ]

Julien Viet updated JBPORTAL-965:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Localization Support bug
> ------------------------
>
>                 Key: JBPORTAL-965
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-965
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: windowxp,ie6,charset=zh-ch
>            Reporter: &#21556;&#22869;&#38596;
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-868) Consumer managed
	state testing
Message-ID: <2576092.1157321274037.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-868?page=all ]

Julien Viet updated JBPORTAL-868:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer managed state testing
> ------------------------------
>
>                 Key: JBPORTAL-868
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-868
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I have added InstanceContext.portletCloned(String portletId, byte[] state) method. We need a test case that retrieves the byte array state from the WSRP PortletContext and makes a callback to the InstanceContext.portletCloned method as we must support consumer state management in our WSRP consumer.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-637) Portlet Container
 test cases beyond "PLT.F TCK Assertions"
Message-ID: <18801427.1157321274179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-637?page=all ]

Julien Viet updated JBPORTAL-637:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portlet Container test cases beyond "PLT.F TCK Assertions"
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-637
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-637
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 hours
>
> Implement portlet container test cases which are not in scope of Portlet Specification TCK Assertions. 
> So any specific test cases which don't belong to http://jira.jboss.com/jira/browse/JBPORTAL-636

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-466)
 JBossRenderRequest needs to
 provide access to the current PortalTheme
Message-ID: <7479912.1157321274308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-466?page=all ]

Julien Viet updated JBPORTAL-466:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> JBossRenderRequest needs to provide access to the current PortalTheme
> ---------------------------------------------------------------------
>
>                 Key: JBPORTAL-466
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-466
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Final
>            Reporter: Martin Holzner
>             Fix For: 2.6.Alpha1
>
>
> This is a feature that Roy needs in one of the CM portlets. 
> There is a temp fix for this already in the RenderPageCommand , but it is a hack. It needs to be revisited! 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-857) Deal with non
 standard Locales better
Message-ID: <14736904.1157321274432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-857?page=all ]

Julien Viet updated JBPORTAL-857:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Deal with non standard Locales better
> -------------------------------------
>
>                 Key: JBPORTAL-857
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-857
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Per the WSRP Spec regarding UnsupportedLocale fault:
> The Portlet does not support generating markup for the requested locale. Since the Portlet is not required to generate markup in the requested locale, a Portlet returning this fault message is indicating that it processes locales in a stricter manner and has no markup for the requested locales. The Consumer can treat this as a specialization of the OperationFailed fault message and does not have to retry getting the markup in other locales.
> Currently, LocaleInfo throws an IllegalArgumentException if the locale is not standard which gets wrapped into an OperationFailedFault at the handler level. We should deal with locale errors better and maybe be more lenient as to what we accept.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-435) Request dumper
	interceptor
Message-ID: <11527757.1157321274573.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-435?page=all ]

Julien Viet updated JBPORTAL-435:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Request dumper interceptor
> --------------------------
>
>                 Key: JBPORTAL-435
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-435
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Server
>            Reporter: Julien Viet
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Ala tomcat : allows to see what parameters a portlet receive

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-372) Basic Publish
 Approval Workflow
Message-ID: <24741810.1157321274795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-372?page=all ]

Julien Viet updated JBPORTAL-372:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Basic Publish Approval Workflow
> -------------------------------
>
>                 Key: JBPORTAL-372
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-372
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: James Williams
>         Assigned To: Roy Russo
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> Optional feature which mandates that  content changes must flow through a simple approval process that involves a Publisher and one or more Managers. Once the publisher makes a content change an email approval request should be sent to the manager list. The content change will not be made available to readers until all Managers approve the change.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:54 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-847) Identify common
 conversion
 methods (from Set<Mode> to String[] for ex) and put them in a utility class
Message-ID: <32274435.1157321274934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-847?page=all ]

Julien Viet updated JBPORTAL-847:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Identify common conversion methods (from Set<Mode> to String[] for ex) and put them in a utility class
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-847
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-847
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> There are several similar versions of such code. Try to find some time and gather all this code in a single spot.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:55 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-528) Management
 portlet creating inaccessible instance with empty name field
Message-ID: <24013160.1157321275336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-528?page=all ]

Julien Viet updated JBPORTAL-528:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Management portlet creating inaccessible instance with empty name field
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-528
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-528
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> as in forum post:
> "From the management portlet (page view), I clicked the button "Add instance" without entering anything in the text field. It created a blank portlet window. Since it has no names, there are no links associated with it. As a result, I can't delete it."

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:55 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-635) Portlet Container
	tests
Message-ID: <19336025.1157321275454.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-635?page=all ]

Julien Viet updated JBPORTAL-635:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portlet Container tests
> -----------------------
>
>                 Key: JBPORTAL-635
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-635
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 days, 7 hours, 30 minutes
>
> Implement full range of tests for portlet container
> - TCK Assertions from Portlet Specification
> - Additional test based on portlet specification to cover any specific behavior of container

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:58 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-467) Login page needs
 to use the theme of the requested portal
Message-ID: <28748039.1157321278760.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-467?page=all ]

Julien Viet updated JBPORTAL-467:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Login page needs to use the theme of the requested portal
> ---------------------------------------------------------
>
>                 Key: JBPORTAL-467
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-467
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Martin Holzner
>             Fix For: 2.6.Alpha1
>
>
> The Login.jsp that the web.xml's form login points to is in the portal-server.war. 
> A call to this jsp does not go through any of the stacks in the portal core, and hence there is no portal or page object available to determine the currently set property for the selected theme. As a result, the Login jsp cannot be styled in synch with the rest of the portal. 
> In the context of having a synchronized look and feel throughout a portal, the login needs to be able to select the same theme as the portal that was requested, so that the login fits seemlessly into the UI flow. 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:58 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-767) ERROR
 [org.apache.myfaces.portlet.MyFacesGenericPortlet]
Message-ID: <1577106.1157321278926.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-767?page=all ]

Julien Viet updated JBPORTAL-767:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> ERROR [org.apache.myfaces.portlet.MyFacesGenericPortlet]
> --------------------------------------------------------
>
>                 Key: JBPORTAL-767
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-767
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final
>         Environment: Mac OS X, jboss-portal-2.2.1RC2-bundled
>            Reporter: Leonard Sitongia
>             Fix For: 2.6.Alpha1
>
>
> (I'm using jboss-portal-2.2.1RC2-bundled, but I'm building and deploying 2.4 from CVS into it.)
> I've used management to create a new page (tab) at the top level, same as default.  I add a few portlets to that, including navigation, user and the CMS content one.  I remove the CMS content one.  Thereafter, when I use management to enter the default portal (by clicking on "default" in the management portlet's navigation tree on the left), I get an exception, and the management portlet is not rendered on the page.
> 2006-03-22 08:26:57,497 ERROR [org.apache.myfaces.portlet.MyFacesGenericPortlet]
>  The portlet threw an exception
> javax.portlet.PortletException: /WEB-INF/jsp/management/index.xhtml @100,58 rend
> ered="#{!empty node.children}": org.jboss.portal.core.portlet.management.LazyPor
> talObjectTreeNode
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.handleExceptionFromL
> ifecycle(MyFacesGenericPortlet.java:254)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesG
> enericPortlet.java:400)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGeneri
> cPortlet.java:266)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContain
> er.java:552)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.j
> ava:464)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInv
> ocation.java:79)
>         at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.j
> ava:142)
> ...
> Thanks,
> ==Leonard

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:59 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-660) Test servlet and
 filter commands
Message-ID: <7066090.1157321279068.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-660?page=all ]

Julien Viet updated JBPORTAL-660:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test servlet and filter commands
> --------------------------------
>
>                 Key: JBPORTAL-660
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-660
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Server
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:07:59 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:07:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-717) Consumer
	localization
Message-ID: <29422501.1157321279231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-717?page=all ]

Julien Viet updated JBPORTAL-717:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer localization
> ---------------------
>
>                 Key: JBPORTAL-717
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-717
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-530) Null Pointer
 Exception in MyFacesGenericPortlet
Message-ID: <619771.1157321280020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-530?page=all ]

Julien Viet updated JBPORTAL-530:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Null Pointer Exception in MyFacesGenericPortlet
> -----------------------------------------------
>
>                 Key: JBPORTAL-530
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-530
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: Jboss 4.0.3 SP1 - portal 2.0.1 RC3
>            Reporter: Stefan Tausendpfund
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>         Attachments: DuplicatePortletTestWeb.tgz
>
>
> Hello,
> the initial post is from the Jboss portal forum. 
> I repost it to attach a sample application showing this error.
> <snip>
> Hello,
> we created an portal application on JBoss Server 4.0.3SP1 with portal 2.0.1RC3 using myfaces MyFacesGenericPortlet. We have several pages and several portlets in one page. One portlet is present in all pages. If I make an action on this portlet (portletwindow0) and switch the page (portletwindow1) i get an NPE in the facesRender method of the MyFacesGenericPortlet.
> The lookup of the faces context with
> ServletFacesContextImpl facesContext = (ServletFacesContextImpl)request.
> getPortletSession().
> getAttribute(CURRENT_FACES_CONTEXT);
> returns a null object and the following statement
> if (facesContext.getResponseComplete()) return;
> fails.
> On first entry of doView the getAttribure looks for an Attribute:
> javax.portlet.p..<portletwindow0>?org.apache.myfaces.portlet.MyFacesGenericPortlet.CURRENT_FACES_CONTEXT
> After switching the page it looks for
> javax.portlet.p..<portletwindow1>?org.apache.myfaces.portlet.MyFacesGenericPortlet.CURRENT_FACES_CONTEXT
> but the facescontext is still with the key window0 in the session.
> Using the same window name in different pages for the same portlet leeds to a portal error. 
> <snap>
> best regards
>    Stefan Tausendpfund

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-522) Edit modes and
 window states in the portalobject manager
Message-ID: <31970112.1157321280151.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-522?page=all ]

Julien Viet updated JBPORTAL-522:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Edit modes and window states in the portalobject manager
> --------------------------------------------------------
>
>                 Key: JBPORTAL-522
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-522
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-328) CMS security
Message-ID: <688501.1157321280357.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-328?page=all ]

Julien Viet updated JBPORTAL-328:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> CMS security
> ------------
>
>                 Key: JBPORTAL-328
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-328
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Improve the current CMS security.
> No check is done at the CMSPortlet level, this is a important missing feature.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-663) Test instance
	container
Message-ID: <20419069.1157321280484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-663?page=all ]

Julien Viet updated JBPORTAL-663:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test instance container
> -----------------------
>
>                 Key: JBPORTAL-663
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-663
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-393) Security audit/log
Message-ID: <4108618.1157321280616.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-393?page=all ]

Julien Viet updated JBPORTAL-393:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Security audit/log
> ------------------
>
>                 Key: JBPORTAL-393
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-393
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Noel Rocher
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> Provide a mean to log and see all security problems that occur.
>  

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:00 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-711) Producer URL
 templating support
Message-ID: <25332178.1157321280789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-711?page=all ]

Julien Viet updated JBPORTAL-711:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer URL templating support
> -------------------------------
>
>                 Key: JBPORTAL-711
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-711
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:01 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-861) Brazilian
 Portguese Portal localization (draft version)
Message-ID: <5470959.1157321281445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-861?page=all ]

Julien Viet updated JBPORTAL-861:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Brazilian Portguese Portal localization (draft version)
> -------------------------------------------------------
>
>                 Key: JBPORTAL-861
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-861
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final
>         Environment: JPortal 2.2.1 RC2
>            Reporter: sumersoft sumersoft
>            Priority: Trivial
>             Fix For: 2.6.Alpha1
>
>         Attachments: Resource_pt_BR.properties
>
>
> Brazilian Portuguese Portal Core translation

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:01 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-895) update myfaces
 libraries to newest release
Message-ID: <28826403.1157321281612.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-895?page=all ]

Julien Viet updated JBPORTAL-895:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> update myfaces libraries to newest release
> ------------------------------------------
>
>                 Key: JBPORTAL-895
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-895
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>         Environment: any
>            Reporter: Danijel Jevtic
>            Priority: Critical
>             Fix For: 2.6.Alpha1
>
>
> Could you please upgrade to the newest tomahawk-version?!

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:01 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-983) Upload of large
	files fails.
In-Reply-To: <24473425.1155836711730.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25129724.1157321281898.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-983?page=all ]

Julien Viet updated JBPORTAL-983:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)
                       (was: 2.4.1 Final)

> Upload of large files fails.
> ----------------------------
>
>                 Key: JBPORTAL-983
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-983
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.4 Final
>         Environment: Windows XP, JDK 1.5, JBoss AS 4.0.4GA
>            Reporter: Peter Johnson
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Using the CMS Admin portlet, I attempted to upload a zip file into a directory, as per section 3.2.9 of the User Guide. Initially I tried a zip ofabout 6MB containing many files, and eventually got down to a a zip file of about 500M with only a single Word document inside.  The upload failed and an "SQLException: could not reset reader" error appeared (see forum post for stack trace).
> I am, however, able to upload very small zip files.
>  

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-667) Refactor the
 command invocation framework
Message-ID: <4039670.1157321282038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-667?page=all ]

Julien Viet updated JBPORTAL-667:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

>  Refactor the command invocation framework
> ------------------------------------------
>
>                 Key: JBPORTAL-667
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-667
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> similarly to the component invocation framework : use a Result object and an handler to decouple the action performed within the server and the action following this action 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-536) Add a
 display-name property
 per portal object that contains a i18n name for displaying object
Message-ID: <10147024.1157321282250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-536?page=all ]

Julien Viet updated JBPORTAL-536:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Add a display-name property per portal object that contains a i18n name for displaying object
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-536
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-536
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-708) Producer simple
 level support (full portlet management interface support)
Message-ID: <1202610.1157321282523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-708?page=all ]

Julien Viet updated JBPORTAL-708:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer simple level support (full portlet management interface support)
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-708
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-708
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-859) Suport portlet
 which use GET method in forms.
Message-ID: <14519780.1157321282769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-859?page=all ]

Julien Viet updated JBPORTAL-859:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Suport portlet which use GET method in forms.
> ---------------------------------------------
>
>                 Key: JBPORTAL-859
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-859
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> We probably need to add an element similar to remotable to the jboss portlet descriptors...
> From WSRP spec (10.2.4 Method=get in HTML forms):
> User-Agents often throw away any query string from the URL indicated with the form's action attribute when generating the URL they will activate when the form's method is "get". This is the simplest means for them to generate a valid query string. The difficulty this causes is that Consumer's often prefer to store the information they will use when a portlet URL is activated as query string parameters. As a result, Portlets that include HTML forms with method=get in their markup MUST specify usesMethodGet as "true" in their PortletDescription. Consumers choosing to use such Portlets need to format their portlet URLs such that portlet URL activations are processed correctly, regardless of whether Consumer or Producer URL writing is in use.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:02 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-504) Migrate the
 features present
 in the UserPortlet on the UserModule as they govern how the service is more
 or less behaves
Message-ID: <27231915.1157321282990.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-504?page=all ]

Julien Viet updated JBPORTAL-504:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Migrate the features present in the UserPortlet on the UserModule as they govern how the service is more or less behaves
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-504
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-504
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Branch, 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-770) Add constant to
 identify default locale when none is given for code requiring locale
Message-ID: <3258957.1157321283186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-770?page=all ]

Julien Viet updated JBPORTAL-770:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Add constant to identify default locale when none is given for code requiring locale
> ------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-770
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-770
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> There are several spots where locales are needed and not always available. It is not clear at this point if the default locale should be Locale.ENGLISH or the user's default locale (Locale.getDefault()). Creating a constant (in PortalConstants e.g.) to encapsulate which "default" locale to use should help.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-746) Enhance
	URLVisitor interface
Message-ID: <10409167.1157321283372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-746?page=all ]

Julien Viet updated JBPORTAL-746:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Enhance URLVisitor interface
> ----------------------------
>
>                 Key: JBPORTAL-746
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-746
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2.1 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> Improve URLVisitor and make the startDir method returns a boolean so the visitor can state if it wants to visit the children or just continue.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-707) Consumer
 registration interface
Message-ID: <10740029.1157321283545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-707?page=all ]

Julien Viet updated JBPORTAL-707:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer registration interface
> -------------------------------
>
>                 Key: JBPORTAL-707
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-707
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 5 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:03 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-842) Protect each
 Producer method with a check of the registration
Message-ID: <33195289.1157321283838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-842?page=all ]

Julien Viet updated JBPORTAL-842:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Protect each Producer method with a check of the registration
> -------------------------------------------------------------
>
>                 Key: JBPORTAL-842
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-842
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 hours
>          Time Spent: 2 hours
>  Remaining Estimate: 1 hour
>
> See MarkupHandler.getMarkup for how it could be done. Possible implementations: use a dynamic proxy on the Producer impl, use AOP, do it manually...

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-910) On 2.4 release
 migration application should be exposed as separate binary
Message-ID: <33081466.1157321284048.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-910?page=all ]

Julien Viet updated JBPORTAL-910:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> On 2.4 release migration application should be exposed as separate binary
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-910
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-910
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Migration
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Rali Genova
>             Fix For: 2.6.Alpha1
>
>
> When 2.4 will be released we should expose Migration Application as separate pre-build web application archive
> It can be placed either at
> - portletswap
> - portal download area at sourceforge
> - both above :)
> and will enable people to avoid building it from sources.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-538) CMSPortlet
 displays only in
 default page when link is clicked on a different page.
Message-ID: <14891344.1157321284313.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-538?page=all ]

Julien Viet updated JBPORTAL-538:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> CMSPortlet displays only in default page when link is clicked on a different page.
> ----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-538
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-538
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.2 Final, 2.4 Final
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> As mentioned here: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3914462

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-894) Add support for
 WSRP resources.
Message-ID: <6628023.1157321284443.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-894?page=all ]

Julien Viet updated JBPORTAL-894:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Add support for WSRP resources.
> -------------------------------
>
>                 Key: JBPORTAL-894
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-894
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPTL-19) PLT.5.2.4.4
 Exceptions During Request Handling : temporary unavailability
Message-ID: <26031721.1157321284557.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-19?page=all ]

Julien Viet updated JBPTL-19:
-----------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> PLT.5.2.4.4 Exceptions During Request Handling : temporary unavailability
> -------------------------------------------------------------------------
>
>                 Key: JBPTL-19
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-19
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-633) Update core
 packaging so it is
 possible to deploy management apps in a separate war that contains tomahawk
Message-ID: <22919969.1157321284674.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-633?page=all ]

Julien Viet updated JBPORTAL-633:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Update core packaging so it is possible to deploy management apps in a separate war that contains tomahawk
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-633
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-633
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:04 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-630) Portal name
Message-ID: <17938967.1157321284878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-630?page=all ]

Julien Viet updated JBPORTAL-630:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portal name
> -----------
>
>                 Key: JBPORTAL-630
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-630
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryszard Kozmik
>         Assigned To: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> I need this: req.getPortalContext().getProperty("org.jboss.portal.property.name"));
> to be able to create root link in JBoss Forums.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-821) Find out to
 properly bind property descriptions to schemas
Message-ID: <26049916.1157321285017.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-821?page=all ]

Julien Viet updated JBPORTAL-821:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Find out to properly bind property descriptions to schemas
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-821
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-821
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.6 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> In RegistrationTestCase:
> PropertyDescription regProp = new PropertyDescription("regProp", new QName("ns1:LocalizedString"),
>          new LocalizedString("en", null, "Registration Property"), null, null);
> The second parameter of the PropertyDescription constructor is a QName indicating the XSD type of the property. However, the namespace prefix must be bound to a URN somehow. Right now, we're using a hack: ns1:LocalizedString is used since it is a WSRP-defined type. We also use ns1 as the namespace prefix since this is the prefix assigned to the WSRP type namespace which allows the WS stack to find the type. However, this is obvious that this is not the correct way to do it and this will have to be addressed for 2.6.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-709) Producer caching
	support
Message-ID: <29574324.1157321285180.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-709?page=all ]

Julien Viet updated JBPORTAL-709:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer caching support
> ------------------------
>
>                 Key: JBPORTAL-709
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-709
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-718) Expose monitoring
 informations for JBoss ON
Message-ID: <18103358.1157321285379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-718?page=all ]

Julien Viet updated JBPORTAL-718:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Expose monitoring informations for JBoss ON
> -------------------------------------------
>
>                 Key: JBPORTAL-718
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-718
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-264) Login module can
 create missing user
Message-ID: <9325526.1157321285552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-264?page=all ]

Julien Viet updated JBPORTAL-264:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Login module can create missing user
> ------------------------------------
>
>                 Key: JBPORTAL-264
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-264
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Add an option to the ModelLoginModule in order that it creates anuser when it does not exist. This would obviously work in conjonction with another login module placed in front of it that would authenticate username/password. The communication between the two modules would be done by using password stacking.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-955) Use globally
 unique (i.e.
 prefixed by org.jboss.portal for ex.) session/invocation attribute names to
 avoid collisions.
In-Reply-To: <23627303.1152885431306.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27035623.1157321285680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-955?page=all ]

Julien Viet updated JBPORTAL-955:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Use globally unique (i.e. prefixed by org.jboss.portal for ex.) session/invocation attribute names to avoid collisions.
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-955
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-955
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-659) Test web app
	instrumentation
Message-ID: <2790211.1157321285810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-659?page=all ]

Julien Viet updated JBPORTAL-659:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test web app instrumentation
> ----------------------------
>
>                 Key: JBPORTAL-659
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-659
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Server
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:05 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-957) Mutliple versions
 of languages in language drop-down in user profile
In-Reply-To: <9192030.1152893351367.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5216128.1157321285924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-957?page=all ]

Julien Viet updated JBPORTAL-957:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Mutliple versions of languages in language drop-down in user profile
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-957
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-957
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-233) User metadata
Message-ID: <21785941.1157321286070.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-233?page=all ]

Julien Viet updated JBPORTAL-233:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> User metadata
> -------------
>
>                 Key: JBPORTAL-233
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-233
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> The portal defines itw own way to manipulate user. The current interface definition is capable to manipulate users. In particular it is possible to use user properties in a dynamic way. However it is not possible to know what properties are supported. Therefore we need to add metadata to the module in order to know informations about the properties available and supported by the portal.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-765) Portlet
 Specification 1.0 API test cases
Message-ID: <25454277.1157321286188.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-765?page=all ]

Julien Viet updated JBPORTAL-765:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Portlet Specification 1.0 API test cases
> ----------------------------------------
>
>                 Key: JBPORTAL-765
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-765
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.6 Final
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 1 hour
>
> Implement test cases for javax.portlet.* classes - Portlet Specification 1.0 API. 
> Test cases should not double assertions already done in:
> Portlet Specification 1.0 "PLT.F TCK Assertions" - (http://jira.jboss.com/jira/browse/JBPORTAL-636)
> Portlet Container test cases beyond "PLT.F TCK Assertions" - (http://jira.jboss.com/jira/browse/JBPORTAL-637)
> This test should assert API contracts like - 'null' argument - IllegalArgumentException is thrown. All implementation or behavioral tests should be done in EXT part (http://jira.jboss.com/jira/browse/JBPORTAL-637)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-860) Update DTDs to
 reflect changes in descriptors.
Message-ID: <590784.1157321286309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-860?page=all ]

Julien Viet updated JBPORTAL-860:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Update DTDs to reflect changes in descriptors.
> ----------------------------------------------
>
>                 Key: JBPORTAL-860
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-860
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Update and document changes. Should we move to XSD since some of the DTD elements don't seem to reflect the internal structure of descriptors.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-283) WSRP producer
Message-ID: <30515714.1157321286705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-283?page=all ]

Julien Viet updated JBPORTAL-283:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> WSRP producer
> -------------
>
>                 Key: JBPORTAL-283
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-283
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>
> Compliant implementation of WSRP producer.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-662) Test portal
	object container
Message-ID: <21028151.1157321286854.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-662?page=all ]

Julien Viet updated JBPORTAL-662:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test portal object container
> ----------------------------
>
>                 Key: JBPORTAL-662
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-662
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:06 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-839) Support
 UploadContext in getMarkup
Message-ID: <18378241.1157321286983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-839?page=all ]

Julien Viet updated JBPORTAL-839:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Support UploadContext in getMarkup
> ----------------------------------
>
>                 Key: JBPORTAL-839
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-839
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:07 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-532) Define CMS
	security
Message-ID: <31148253.1157321287192.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-532?page=all ]

Julien Viet updated JBPORTAL-532:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Define CMS security
> -------------------
>
>                 Key: JBPORTAL-532
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-532
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Explore the different possbilities of the cms security :
> - define what resources are secured (it should be directories and content)
> - define the security model : the different actions on nodes and their relationship accross the resources (i.e what implies what between different resources)
> - see if the new portal security module can handle that
> - where to apply runtime checks

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:07 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-438) Preference Values
 whose length is greater than 255 characters cannot be saved
Message-ID: <11751787.1157321287329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-438?page=all ]

Julien Viet updated JBPORTAL-438:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Preference Values whose length is greater than 255 characters cannot be saved
> -----------------------------------------------------------------------------
>
>                 Key: JBPORTAL-438
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-438
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.0 Final, 2.0 Branch, 2.4 Final, 2.2 Branch
>         Environment: Windows 2000, JBAS 4.02
>            Reporter: Dennis Meers
>             Fix For: 2.6.Alpha1
>
>
> If you create a portlet that supports EDIT mode and a logged-in user edits a preference, if the value they put in has more than 255 chars, an error occurs.  This is because the table that saves user preference values (jbp_user_pref_value) has a column called 'jbp_value' that is defined as 'VARCHAR(255)'.
> I don't know if the portlet spec defines how many characters are allowed in a preference value, but 255 characters seems small for some portlets.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-337) remove the
 unnecessary and add necessary operations from UserPortlet
Message-ID: <10394589.1157321288198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-337?page=all ]

Julien Viet updated JBPORTAL-337:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> remove the unnecessary and add necessary operations from UserPortlet
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-337
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-337
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Branch
>         Environment: Linux, PostgreSQL, AS 4.0.2
>            Reporter: Yang
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: UserPortlet.diff
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> For core/src/main/org/jboss/portal/core/portlet/user/UserPortlet.java, the operations like SHOW_LOGIN and SHOW_MENU shouldn't be included in UserPortlet. 
> However, operations like FORGETPASSWORD and ACTIVATEACCOUNT should be included. 

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-880) Move
 PortalDeployment classes to JBoss XB
Message-ID: <5126643.1157321288329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-880?page=all ]

Julien Viet updated JBPORTAL-880:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Move PortalDeployment classes to JBoss XB
> -----------------------------------------
>
>                 Key: JBPORTAL-880
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-880
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 days
>          Time Spent: 5 hours
>  Remaining Estimate: 2 days, 3 hours
>
> Portal deployment files are currently "manually" parsed via the common.util.XML class. Leveraging JBoss XB should allow for easier maintenance and possibly speed.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-977) 403 error when
 logging in as admin with LDAP
In-Reply-To: <13281047.1154637371578.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29278203.1157321288441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-977?page=all ]

Julien Viet updated JBPORTAL-977:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)
                       (was: 2.4.1 Final)

> 403 error when logging in as admin with LDAP
> --------------------------------------------
>
>                 Key: JBPORTAL-977
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-977
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final
>         Environment: Portal 2.4 CR3 bundled
>            Reporter: Kevin Barfield
>             Fix For: 2.6.Alpha1
>
>
> A 403 error is shown when logging in as admin using LDAP.  Open a new browser, and now you are logged in.  Same issue with logout.  Logging in as a regular user is fine.
> Here is the login config:
> <policy>
>    <!-- For the JCR CMS -->
>    <application-policy name="cms">
>       <authentication>
>          <login-module code="org.apache.jackrabbit.core.security.SimpleLoginModule" flag="required"/>
>       </authentication>
>    </application-policy>
>    
>    <application-policy name="portal">
>       <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule" flag="required">
>                             <module-option name="java.naming.factory.initial"> 
>                                 com.sun.jndi.ldap.LdapCtxFactory
>                                 </module-option>
>                             <module-option name="java.naming.provider.url">
>                                 ldap://localhost/
>                             </module-option>
>                             <module-option name="java.naming.security.authentication">
>                                 simple
>                             </module-option>
>                             <module-option name="java.naming.security.principal">
>       		       cn=Manager,dc=example,dc=com
>                             </module-option>
>                             <module-option name="java.naming.security.credentials">
>       		        secret
>                             </module-option>
>                             <module-option name="principalDNPrefix">cn=</module-option>                    
>                             <module-option name="principalDNSuffix">
>                                 ,ou=people,dc=example,dc=com
>                             </module-option>
>                         <module-option name="password-stacking">useFirstPass</module-option>
>                             <module-option name="rolesCtxDN">
>                                 ou=groups,dc=example,dc=com
>                             </module-option>
>                             <module-option name="uidAttributeID">member</module-option>
>                             <module-option name="matchOnUserDN">true</module-option>
>                             <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false </module-option>
>          <!--
>          <login-module code="org.jboss.portal.identity.auth.IdentityLoginModule" flag="required">
>             <module-option name="unauthenticatedIdentity">guest</module-option>
>             <module-option name="userModuleJNDIName">java:/portal/UserModule</module-option>
>             <module-option name="roleModuleJNDIName">java:/portal/RoleModule</module-option>
>             <module-option name="additionalRole">Authenticated</module-option>
>             <module-option name="password-stacking">useFirstPass</module-option>
>             -->
>          </login-module>
>       </authentication>
>    </application-policy>
> </policy>

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:08 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:08 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-455) Relax portlet
 security roles declaration
Message-ID: <1303531.1157321288590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-455?page=all ]

Julien Viet updated JBPORTAL-455:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Relax portlet security roles declaration
> ----------------------------------------
>
>                 Key: JBPORTAL-455
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-455
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.0 Final
>            Reporter: Julien Viet
>             Fix For: 2.6.Alpha1
>
>
> Today when a portlet uses the req.isUserInRole(String roleName), this role must be declared in the portlet.xml otherwise the method returns false.
> <portlet>
>    ...
>    <security-role-ref>
>       <role-name>Admin</role-name>
>    </security-role-ref>
>    ...
> </portlet>
> This is what the portlet spec tells to do.
> But it could be possible to avoid this declaration and let all the role checks pass through and delegate the call to the servlet container when configuring jboss portal
> in a certain mode (at server level or webapp level)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-558) Navigation with
 JSF/Facelets broken with multiple portlets in one page
Message-ID: <28267268.1157321289149.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-558?page=all ]

Julien Viet updated JBPORTAL-558:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Navigation with JSF/Facelets broken with multiple portlets in one page
> ----------------------------------------------------------------------
>
>                 Key: JBPORTAL-558
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-558
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2 Final
>         Environment: Linux Red Hat Enterprise Server 4 64 Bit, JDK 1.5.0_06
>            Reporter: gressho
>             Fix For: 2.6.Alpha1
>
>
> Navigation results in JSF/Facelet appear allways in the first portlet of the page. The "result" is the same, but "from" and "to" aren't.
> Everything works correct with JSF/JSP.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-875) Test WSRP
 implementation conformance
Message-ID: <16686756.1157321289273.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-875?page=all ]

Julien Viet updated JBPORTAL-875:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Test WSRP implementation conformance
> ------------------------------------
>
>                 Key: JBPORTAL-875
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-875
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Critical
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days
>  Remaining Estimate: 0 minutes
>
> Run WSRPtk to test implementation conformance.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-822) Ensure that
 producer is back
 to a default state before the beginning of each test.
Message-ID: <29255109.1157321289399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-822?page=all ]

Julien Viet updated JBPORTAL-822:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Ensure that producer is back to a default state before the beginning of each test.
> ----------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-822
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-822
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 3 hours
>  Remaining Estimate: 3 hours
>
> Make sure that producer is in a correct neutral state before the beginning of each test (been tracking a test issue for a couple of hours that was due to the producer not being in the expected state :( )...

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:09 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-712) Producer
 persistent local state
Message-ID: <25207537.1157321289565.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-712?page=all ]

Julien Viet updated JBPORTAL-712:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Producer persistent local state
> -------------------------------
>
>                 Key: JBPORTAL-712
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-712
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:10 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-768) Russian Portal
 localization (draft version)
Message-ID: <25253025.1157321290022.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-768?page=all ]

Julien Viet updated JBPORTAL-768:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Russian Portal localization (draft version)
> -------------------------------------------
>
>                 Key: JBPORTAL-768
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-768
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final
>         Environment: JPortal 2.2.1 RC2
>            Reporter: Mike Khlu
>            Priority: Trivial
>             Fix For: 2.6.Alpha1
>
>         Attachments: Resource_ru.properties, Resource_ru.properties
>
>
> I'm translate all rows. But portal use only 30% from all strings. i18n may be buggy.
> I think than you can put this file to you future portal releases/

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:08:10 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:08:10 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-714) Consumer medium
 level support (full portlet management interface support)
Message-ID: <15389798.1157321290172.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-714?page=all ]

Julien Viet updated JBPORTAL-714:
---------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.6 Final)

> Consumer medium level support (full portlet management interface support)
> -------------------------------------------------------------------------
>
>                 Key: JBPORTAL-714
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-714
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:17:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9985530.1157321863959.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Julien Viet reopened JBPORTAL-964:
----------------------------------

      Assignee: Roy Russo
             
To be fixed in 2.4.1 actually

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:17:44 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 3 Sep 2006 18:17:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9268689.1157321864106.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Julien Viet updated JBPORTAL-964:
---------------------------------

    Fix Version/s: 2.4.1 Final
                       (was: 2.6 Final)

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:21:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-991) UI for user
	creation of pages
In-Reply-To: <7869311.1156184621943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27085329.1157322103846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-991?page=all ]

Roy Russo updated JBPORTAL-991:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI for user creation of pages
> -----------------------------
>
>                 Key: JBPORTAL-991
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-991
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>
> Allow users to create and define page properties.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:23:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:23:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-992) UI for user
	editting of pages
In-Reply-To: <5304149.1156184740617.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9439867.1157322223789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-992?page=all ]

Roy Russo updated JBPORTAL-992:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI for user editting of pages
> -----------------------------
>
>                 Key: JBPORTAL-992
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-992
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1017) Submenu support
 in NavigationPortlet
In-Reply-To: <8700605.1157138144292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12474666.1157322344257.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1017?page=all ]

Roy Russo updated JBPORTAL-1017:
--------------------------------

    Fix Version/s: 2.6.Alpha1

> Submenu support in NavigationPortlet
> ------------------------------------
>
>                 Key: JBPORTAL-1017
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1017
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-825) Usability
 improvements in Admin UI
Message-ID: <11706170.1157322344396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-825?page=all ]

Roy Russo updated JBPORTAL-825:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> Usability improvements in Admin UI
> ----------------------------------
>
>                 Key: JBPORTAL-825
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-825
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Address usability issues with interface redesign, tooltips, and help mode in management portlet.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1007) Fix drag & drop
 code to work in Konqueror
In-Reply-To: <2383186.1156994624285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10723874.1157322344552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1007?page=all ]

Roy Russo updated JBPORTAL-1007:
--------------------------------

    Affects Version/s: 2.6.Alpha1

> Fix drag & drop code to work in Konqueror
> -----------------------------------------
>
>                 Key: JBPORTAL-1007
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1007
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Konqueror
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> check with Tomek.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-994) UI enhancements
 to bundled portlets
In-Reply-To: <28222267.1156185580797.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20121212.1157322344673.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-994?page=all ]

Roy Russo updated JBPORTAL-994:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI enhancements to bundled portlets
> -----------------------------------
>
>                 Key: JBPORTAL-994
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-994
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> userportlet
> roleportlet
> cmsadmin
> cms content
> managementportlet

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1006) Fix drag & drop
 code to work in IE
In-Reply-To: <9281802.1156994623979.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26976772.1157322344842.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1006?page=all ]

Roy Russo updated JBPORTAL-1006:
--------------------------------

    Affects Version/s: 2.6.Alpha1

> Fix drag & drop code to work in IE
> ----------------------------------
>
>                 Key: JBPORTAL-1006
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1006
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Internet Explorer
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Drag&drop javascript code currently works fine in Firefox. Check with Tomek.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-989) Create new
	Default Theme
In-Reply-To: <30876246.1156181504563.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9017855.1157322344972.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-989?page=all ]

Roy Russo updated JBPORTAL-989:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> Create new Default Theme
> ------------------------
>
>                 Key: JBPORTAL-989
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-989
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Use mockup v3 to generate CSS theme.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:45 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-990) AJAX lib to allow
 user positioning of windows
In-Reply-To: <25250425.1156182220833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13368241.1157322345248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-990?page=all ]

Roy Russo updated JBPORTAL-990:
-------------------------------

    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> AJAX lib to allow user positioning of windows
> ---------------------------------------------
>
>                 Key: JBPORTAL-990
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-990
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>
> Implement an AJAX lib to allow user positioning of windows.

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:45 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-887) Portal UI
 usuability improvements
Message-ID: <12033745.1157322345396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-887?page=all ]

Roy Russo updated JBPORTAL-887:
-------------------------------

    Affects Version/s: 2.6.Alpha1
                           (was: 2.2 Branch)

> Portal UI usuability improvements
> ---------------------------------
>
>                 Key: JBPORTAL-887
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-887
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Roy Russo
>            Priority: Optional
>             Fix For: 2.6.Alpha1
>
>
> some stuff that can be improved in UI Usuability
> 1) In Admin Portlet when you add portlet instances to a page the list of them is not sorted anyway so it's hard to fine what you want. Plus possibly with many portlets it will be hard to handle it from drop down list

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 18:25:45 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 3 Sep 2006 18:25:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-993) UI for users
 adding windows to a page
In-Reply-To: <21966823.1156184862411.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24462326.1157322345507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-993?page=all ]

Roy Russo updated JBPORTAL-993:
-------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.6.Alpha1
                           (was: 2.6 Final)

> UI for users adding windows to a page
> -------------------------------------
>
>                 Key: JBPORTAL-993
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-993
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep  3 20:37:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sun, 3 Sep 2006 20:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-115) NPE in ViewTopic
In-Reply-To: <1960202.1154560871633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26161268.1157330263963.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-115?page=comments#action_12342719 ] 
            
Ryszard Kozmik commented on JBFORUMS-115:
-----------------------------------------

I noticed that this exception is thrown only when accessing TopicView by external link. If you navigate normally to specified topic you won't get this exception. Moreover, this problem occurs in any topic, not just in this one.

> NPE in ViewTopic
> ----------------
>
>                 Key: JBFORUMS-115
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-115
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>
> Clicking this link http://forums.proto.jboss.com:8080/portal/index.html?ctrl:cmd=render&ctrl:window=default.default.DefaultCMSPortletWindow&t=12&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2Fviews%2Ftopics%2Fviewtopic_body.jsf , causes whole forums to dissapear and throw this exception:
> 18:06:20,855 ERROR [[/portal-forums]] Exception in FacesServlet
> java.lang.NullPointerException
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:393)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:94)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:128)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContainer.java:521)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.java:433)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInvocation.java:79)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.component.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.component.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.NavigationInterceptor.invoke(NavigationInterceptor.java:76)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.CacheInterceptor.invoke(CacheInterceptor.java:111)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ModesInterceptor.invoke(ModesInterceptor.java:88)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:87)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPostDispatchInterceptor.invoke(SessionPostDispatchInterceptor.java:65)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:129)
>         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.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:101)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
>         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>         at org.jboss.portal.server.app.impl.AbstractRequestContext.include(AbstractRequestContext.java:247)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:73)
>         at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:81)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:79)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPreDispatchInterceptor.invoke(SessionPreDispatchInterceptor.java:94)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.ValveInterceptor.invoke(ValveInterceptor.java:64)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:84)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:68)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:141)
>         at org.jboss.portal.core.command.RenderPageCommand.renderPortlets(RenderPageCommand.java:231)
>         at org.jboss.portal.core.command.RenderPageCommand.execute(RenderPageCommand.java:164)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:58)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:93)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:151)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:77)
>         at org.jboss.portal.core.CoreController.handle(CoreController.java:190)
>         at sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
>         at $Proxy136.handle(Unknown Source)
>         at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:76)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.server.SubjectAssociationInterceptor.invoke(SubjectAssociationInterceptor.java:47)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.PolicyAssociationInterceptor.invoke(PolicyAssociationInterceptor.java:52)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:69)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:184)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:87)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java:75)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:221)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 22:27:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Sun, 3 Sep 2006 22:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-298) Throws
 CurrentModificationException when start several consoles running our
 application
Message-ID: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>

Throws CurrentModificationException when start several consoles running our application
---------------------------------------------------------------------------------------

                 Key: JGRP-298
                 URL: http://jira.jboss.com/jira/browse/JGRP-298
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3
         Environment: Windows XP, JDK 5.0
            Reporter: Sammi Ting
         Assigned To: Bela Ban
            Priority: Minor


Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37

2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
....
2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
	at org.jgroups.protocols.TP.down(TP.java:673)
	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 22:29:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Sun, 3 Sep 2006 22:29:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-298) Throws
 CurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22517182.1157336983954.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Sammi Ting updated JGRP-298:
----------------------------

    Attachment: debug.log

> Throws CurrentModificationException when start several consoles running our application
> ---------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Sun Sep  3 22:37:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Sun, 3 Sep 2006 22:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-298) Throws
 ConcurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5571195.1157337463885.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Sammi Ting updated JGRP-298:
----------------------------

    Summary: Throws ConcurrentModificationException when start several consoles running our application  (was: Throws CurrentModificationException when start several consoles running our application)

> Throws ConcurrentModificationException when start several consoles running our application
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 01:13:46 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Mon, 4 Sep 2006 01:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-360) wrong spelling in
 Hibernate Code Generation window
In-Reply-To: <12128434.1157316703833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11370030.1157346827001.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-360?page=all ]

Max Andersen closed JBIDE-360.
------------------------------

    Fix Version/s: 2.0.0.Beta2
       Resolution: Done

fixed thanks

> wrong spelling in Hibernate Code Generation window
> --------------------------------------------------
>
>                 Key: JBIDE-360
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-360
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>            Priority: Trivial
>             Fix For: 2.0.0.Beta2
>
>
> wrong spelling in Hibernate Code Generation window => "Main" tab => "Dectect optimistic lock columns" checkbox.
> instead of "Dectect" it should be "Detect"

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 01:43:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 01:43:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-298) Throws
 ConcurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7804528.1157348623871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Bela Ban updated JGRP-298:
--------------------------

    Fix Version/s: 2.4
      Description: 
Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37

2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
....
2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;
send_buf_size=100000;loopback=true):TCPPING(timeout=3000;
initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):
FD(timeout=2000;max_tries=4):
VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):
pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;
max_bytes=40000000;down_thread=false;up_thread=false):
VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):
pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
	at org.jgroups.protocols.TP.down(TP.java:673)
	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

  was:
Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37

2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
....
2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;send_buf_size=100000;loopback=true):TCPPING(timeout=3000;initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):FD(timeout=2000;max_tries=4):VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;max_bytes=40000000;down_thread=false;up_thread=false):VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
java.util.ConcurrentModificationException
	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
	at org.jgroups.protocols.TP.down(TP.java:673)
	at org.jgroups.stack.DownHandler.run(Protocol.java:121)


> Throws ConcurrentModificationException when start several consoles running our application
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;
> send_buf_size=100000;loopback=true):TCPPING(timeout=3000;
> initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):
> FD(timeout=2000;max_tries=4):
> VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
> pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):
> pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;
> max_bytes=40000000;down_thread=false;up_thread=false):
> VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):
> pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 02:01:43 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Mon, 4 Sep 2006 02:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-298) Throws
 ConcurrentModificationException when start several consoles running our
 application
In-Reply-To: <28632417.1157336863887.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1198841.1157349703853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-298?page=all ]

Sammi Ting closed JGRP-298.
---------------------------

    Resolution: Done

Found 2.4 should solve the problem.

> Throws ConcurrentModificationException when start several consoles running our application
> ------------------------------------------------------------------------------------------
>
>                 Key: JGRP-298
>                 URL: http://jira.jboss.com/jira/browse/JGRP-298
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3
>         Environment: Windows XP, JDK 5.0
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: debug.log
>
>
> Extracted from log file, start at 2006-09-02 12:33:33 and throw exception at 2006-09-02 12:33:37
> 2006-09-02 12:33:33,945 DEBUG [ main] foundation.connectivity.L2Main#getClassBaseName() -  className = 'L2Main'
> ....
> 2006-09-02 12:33:37,793 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  channel is null
> 2006-09-02 12:33:37,809 DEBUG [ main] connectivity.jgroups.JGroupsNetworkConnectionManager#connect() -  props = 'TCP(enable_diagnostics=false;start_port=8000;recv_buf_size=200000;
> send_buf_size=100000;loopback=true):TCPPING(timeout=3000;
> initial_hosts=10.253.1.74[8000];port_range=4;num_initial_members=4):
> FD(timeout=2000;max_tries=4):
> VERIFY_SUSPECT(timeout=1500;down_thread=false;up_thread=false):
> pbcast.NAKACK(gc_lag=100;retransmit_timeout=600,1200,2400,4800):
> pbcast.STABLE(stability_delay=500;desired_avg_gossip=20000;
> max_bytes=40000000;down_thread=false;up_thread=false):
> VIEW_SYNC(down_thread=false;avg_send_interval=60000;up_thread=false):
> pbcast.GMS(print_local_addr=true;join_timeout=5000;join_retry_timeout=2000;shun=true)'
> 2006-09-02 12:33:40,660 ERROR [ DownHandler (TCP)] jgroups.stack.DownHandler#run() -  DownHandler (TCP) caught exception
> java.util.ConcurrentModificationException
> 	at java.util.HashMap$HashIterator.remove(HashMap.java:806)
> 	at java.util.AbstractCollection.retainAll(AbstractCollection.java:393)
> 	at org.jgroups.blocks.ConnectionTable.retainAll(ConnectionTable.java:393)
> 	at org.jgroups.protocols.TCP.handleDownEvent(TCP.java:188)
> 	at org.jgroups.protocols.TP.down(TP.java:673)
> 	at org.jgroups.stack.DownHandler.run(Protocol.java:121)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 03:33:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 03:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-655) Refactor @Service
	beans
In-Reply-To: <30703765.1153251191416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16370014.1157355223871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-655?page=all ]

Carlo de Wolf updated EJBTHREE-655:
-----------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Refactor @Service beans
> -----------------------
>
>                 Key: EJBTHREE-655
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-655
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Refactor @Service beans to fix a number of problems:
> * magic methods for lifecycle methods:
>   - create/start/stop/destroy
> * lifecycle methods are not required to be in @Management (MBean) interface.
> * @Management interface is not registered with the ServiceController (Controller in MC land).  It *IS* registered as a regular MBean though.
> * If lifecycle methods exist on @Management interface, they must be intercepted on the container so that the appropriate Controler start/stop is done on the container.  This would mean that you have to specify a <bind> in the Service aspect domain in ejb3-interceptors-aop.xml

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 04:45:44 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 4 Sep 2006 04:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-447) correct
 NullPointer when processing PRIORITY rule tag
In-Reply-To: <21683851.1156360189213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13424503.1157359544045.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-447?page=comments#action_12342731 ] 
            
Michael Neale commented on JBRULES-447:
---------------------------------------

ah right... well priority isn't really meant to work that way, you need to set it on each rule row (you can merge cells so you only set it once). 

Still, a NPE should not be thrown, either it should apply the Priority to all, or else give an explicit failure message.

The same could be said of other rule attributes that can be set. I may apply this to TRUNK (but not to 3.0.x) - thanks !

> correct NullPointer when processing PRIORITY rule tag
> -----------------------------------------------------
>
>                 Key: JBRULES-447
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-447
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Michael Neale
>         Attachments: jboss_rules_priority.diff, PriorityTest.xls
>
>
> diff attached. I'm not sure if using LshBuilder is the correct thing to do ...

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 04:49:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 4 Sep 2006 04:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-444) patch to support
 Notes attribute on decision table Package
In-Reply-To: <9769524.1156268351914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11630007.1157359783844.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-444?page=comments#action_12342732 ] 
            
Michael Neale commented on JBRULES-444:
---------------------------------------

Thanks ! Will apply to trunk (not to 3.0.x branch).

> patch to support Notes attribute on decision table Package
> ----------------------------------------------------------
>
>                 Key: JBRULES-444
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-444
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: G?bor Lipt?k
>         Assigned To: Mark Proctor
>            Priority: Optional
>             Fix For: 3.0.4
>
>         Attachments: jboss_rules_decisiontable_package_notes.diff
>
>
> patch attached

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 05:17:48 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 4 Sep 2006 05:17:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-435) Large integer
 values in
 decision tables are converted to scientific notation in DRL which cannot be
 parsed
In-Reply-To: <8098647.1155759034300.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23611920.1157361468776.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-435?page=comments#action_12342734 ] 
            
Michael Neale commented on JBRULES-435:
---------------------------------------

hmmm... yes. A few ways to solve this.

The immediate workaround is to make it text in the spreadsheet cell, not a number, then it should come out verbatim.

Otherwise we can either 
a) make the DRL support scientific notation
b) make the XLS parser convert it to long notation form.

> Large integer values in decision tables are converted to scientific notation in DRL which cannot be parsed
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-435
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-435
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Drl Parser/Builder
>            Reporter: Volker Augustin
>         Assigned To: Michael Neale
>
> When a condition column in a decision table contains values like 25000000, this is compiled using the SpreadsheetCompiler into 2.5E7 in the DRL. However, the DRL parser/compiler cannot cope with this notation and exists with a unexpected token "E7" error 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

        


From jira-events at jboss.com  Mon Sep  4 05:29:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 05:29:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21307845.1157362183781.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-296?page=comments#action_12342735 ] 
            
Bela Ban commented on JGRP-296:
-------------------------------

The properties will be documented here: http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps

> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 05:41:44 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 05:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-667) IIOP binding
In-Reply-To: <28082874.1154072651386.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18958733.1157362904526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-667?page=all ]

Carlo de Wolf resolved EJBTHREE-667.
------------------------------------

    Resolution: Done

> IIOP binding
> ------------
>
>                 Key: EJBTHREE-667
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-667
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Make IIOP binding work in the EJB3 stack.
> To use IIOP on an EJB bean, the following code is used:
> @RemoteBinding(factory=org.jboss.ejb3.iiop.IORFactory.class)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 06:05:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 4 Sep 2006 06:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3522) Include jbossws-1.0.3
In-Reply-To: <18625778.1155717623768.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21268304.1157364343801.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3522?page=all ]

Dimitris Andreadis closed JBAS-3522.
------------------------------------

    Fix Version/s: JBossAS-4.0.5.CR1
                       (was: JBossAS-4.0.5.GA)
       Resolution: Out of Date

This update was scheduled for 4.0.5.GA, but took place in 4.0.5.CR1

> Include jbossws-1.0.3
> ---------------------
>
>                 Key: JBAS-3522
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3522
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep  4 06:09:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 06:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2854013.1157364583897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-296?page=all ]

Bela Ban updated JGRP-296:
--------------------------

    Description: 
- bind.address
- ignore.bind.address
- jboss.tcpping.initial_hosts
- jboss.partition.udpPort
- jboss.partition.udpGroup
- jboss.mcast.ip.ttl

#1 Collect all system properties used by JGroups
#2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
#3 Document all properties used by JGroups
#4 Implement support for both new and old system properties: try to get the value for the new one first (e.g. jgroups.bind_addr), then - if not found - the old one (bind.address). In this case, it probably makes sense to create a function in Util which does this, plus also takes jgroups.ignore.bind_addr into account

  was:
- bind.address
- ignore.bind.address
- jboss.tcpping.initial_hosts
- jboss.partition.udpPort
- jboss.partition.udpGroup
- jboss.mcast.ip.ttl

#1 Collect all system properties used by JGroups
#2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
#3 Document all properties used by JGroups


> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups
> #4 Implement support for both new and old system properties: try to get the value for the new one first (e.g. jgroups.bind_addr), then - if not found - the old one (bind.address). In this case, it probably makes sense to create a function in Util which does this, plus also takes jgroups.ignore.bind_addr into account

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 06:25:43 2006
From: jira-events at jboss.com (Valerij Timofeev (JIRA))
Date: Mon, 4 Sep 2006 06:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20785850.1157365543845.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=comments#action_12342739 ] 
            
Valerij Timofeev commented on JBSEAM-340:
-----------------------------------------

A seam-gen generated scaffold application  relies only on the Seam properties files, for example :

@NotNull
@Length(min = 1, max = 50, message = "#{messages['err.fullname.length']}")
    public String getFullname()
    {
        return fullname;
    }

According entry in a properties file can look so:

err.fullname.length        = Fullname is mandatory and should be maximal 50 characters long

The problem is obvious: max length information is spread among two places :-(

The following form unfortunately doesn't work

err.fullname.length        = Fullname is mandatory and should be maximal {max} characters long

I suppose this could be a feature request: Seam messages must be able to interpret hibernate-validator alike variables {max}


> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Mon Sep  4 07:07:44 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 07:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-653) No pooling for
 stateless session beans
In-Reply-To: <12321988.1153207692016.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25389221.1157368064397.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-653?page=all ]

Carlo de Wolf reassigned EJBTHREE-653:
--------------------------------------

    Assignee: Carlo de Wolf

> No pooling for stateless session beans
> --------------------------------------
>
>                 Key: EJBTHREE-653
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: OS: Windows XP SP2
> JDK 1.5.0_06_b05
> JBoss AS 4.0.4 GA
>            Reporter: Guido Bening
>         Assigned To: Carlo de Wolf
>
> Scenario:
> Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
> The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
> CallBack method:
>     /**
>      * EJBCreate method.
>      */
>     @PostConstruct
>     public void ejb3Create() {
>         System.out.println("New SessionBean " + this);
>         System.out.println("Thread " + Thread.currentThread().getId());
>         setupBean();
>     }
>     
> And the log for a few of the 1000 calls:
> ...
> 09:17:51,119 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 231ae2
> 09:17:51,129 INFO  [STDOUT] Thread 97
> 09:17:51,139 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1662174
> 09:17:51,139 INFO  [STDOUT] Thread 97
> 09:17:51,219 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 189f155
> 09:17:51,219 INFO  [STDOUT] Thread 97
> 09:17:51,239 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a82dfb
> 09:17:51,239 INFO  [STDOUT] Thread 97
> 09:17:51,289 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 198813a
> 09:17:51,289 INFO  [STDOUT] Thread 97
> 09:17:51,309 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 59eefd
> 09:17:51,309 INFO  [STDOUT] Thread 97
> 09:17:51,359 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 2e3520
> 09:17:51,369 INFO  [STDOUT] Thread 97
> 09:17:51,379 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1ed457
> 09:17:51,379 INFO  [STDOUT] Thread 97
> 09:17:51,439 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1e1c7f3
> 09:17:51,439 INFO  [STDOUT] Thread 97
> 09:17:51,449 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 15cb8ed
> 09:17:51,449 INFO  [STDOUT] Thread 97
> 09:17:51,519 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a4a949
> 09:17:51,519 INFO  [STDOUT] Thread 97
> 09:17:51,529 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19ae0a
> 09:17:51,529 INFO  [STDOUT] Thread 97
> 09:17:51,589 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 567fa0
> 09:17:51,599 INFO  [STDOUT] Thread 97
> 09:17:51,609 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19956fe
> 09:17:51,609 INFO  [STDOUT] Thread 97
> 09:17:51,659 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 150e574
> 09:17:51,669 INFO  [STDOUT] Thread 97
> 09:17:51,679 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at aa46ad
> 09:17:51,679 INFO  [STDOUT] Thread 97
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 07:37:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 07:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-653) No pooling for
 stateless session beans
In-Reply-To: <12321988.1153207692016.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28291299.1157369863907.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-653?page=comments#action_12342741 ] 
            
Carlo de Wolf commented on EJBTHREE-653:
----------------------------------------

Test in in regression/ejbthree653

> No pooling for stateless session beans
> --------------------------------------
>
>                 Key: EJBTHREE-653
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: OS: Windows XP SP2
> JDK 1.5.0_06_b05
> JBoss AS 4.0.4 GA
>            Reporter: Guido Bening
>         Assigned To: Carlo de Wolf
>
> Scenario:
> Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
> The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
> CallBack method:
>     /**
>      * EJBCreate method.
>      */
>     @PostConstruct
>     public void ejb3Create() {
>         System.out.println("New SessionBean " + this);
>         System.out.println("Thread " + Thread.currentThread().getId());
>         setupBean();
>     }
>     
> And the log for a few of the 1000 calls:
> ...
> 09:17:51,119 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 231ae2
> 09:17:51,129 INFO  [STDOUT] Thread 97
> 09:17:51,139 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1662174
> 09:17:51,139 INFO  [STDOUT] Thread 97
> 09:17:51,219 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 189f155
> 09:17:51,219 INFO  [STDOUT] Thread 97
> 09:17:51,239 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a82dfb
> 09:17:51,239 INFO  [STDOUT] Thread 97
> 09:17:51,289 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 198813a
> 09:17:51,289 INFO  [STDOUT] Thread 97
> 09:17:51,309 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 59eefd
> 09:17:51,309 INFO  [STDOUT] Thread 97
> 09:17:51,359 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 2e3520
> 09:17:51,369 INFO  [STDOUT] Thread 97
> 09:17:51,379 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1ed457
> 09:17:51,379 INFO  [STDOUT] Thread 97
> 09:17:51,439 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1e1c7f3
> 09:17:51,439 INFO  [STDOUT] Thread 97
> 09:17:51,449 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 15cb8ed
> 09:17:51,449 INFO  [STDOUT] Thread 97
> 09:17:51,519 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a4a949
> 09:17:51,519 INFO  [STDOUT] Thread 97
> 09:17:51,529 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19ae0a
> 09:17:51,529 INFO  [STDOUT] Thread 97
> 09:17:51,589 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 567fa0
> 09:17:51,599 INFO  [STDOUT] Thread 97
> 09:17:51,609 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19956fe
> 09:17:51,609 INFO  [STDOUT] Thread 97
> 09:17:51,659 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 150e574
> 09:17:51,669 INFO  [STDOUT] Thread 97
> 09:17:51,679 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at aa46ad
> 09:17:51,679 INFO  [STDOUT] Thread 97
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 08:19:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 4 Sep 2006 08:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
Message-ID: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
-------------------------------------------------------------------------------------------

                 Key: JBAS-3620
                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
             Fix For: JBossAS-4.0.5.GA


JBossMQ's PersistenceManager has a mechanism to retry recovery
a number of times "RecoveryRetries".

However, this only applies to the data recovery. If it fails 
(e.g. due to database or network glitch)
while checking/creating the database schema
then no retries are done.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 08:27:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 4 Sep 2006 08:27:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
In-Reply-To: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25617993.1157372864038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3620?page=all ]

Adrian Brock updated JBAS-3620:
-------------------------------

    Workaround Description: 
Boot JBoss once to create the tables (or create them manually)
then change the persistence manager config to:
CREATE_TABLES_ON_STARTUP = FALSE
                Workaround: [Workaround Exists]

> JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBossMQ's PersistenceManager has a mechanism to retry recovery
> a number of times "RecoveryRetries".
> However, this only applies to the data recovery. If it fails 
> (e.g. due to database or network glitch)
> while checking/creating the database schema
> then no retries are done.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 09:05:43 2006
From: jira-events at jboss.com (Heiko W. Rupp (JIRA))
Date: Mon, 4 Sep 2006 09:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3621) Possible bad
 implementation of compareOID()
Message-ID: <26398861.1157375143836.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible bad implementation of compareOID()
-------------------------------------------

                 Key: JBAS-3621
                 URL: http://jira.jboss.com/jira/browse/JBAS-3621
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Heiko W. Rupp
         Assigned To: Heiko W. Rupp




-- 
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

        


From jira-events at jboss.com  Mon Sep  4 09:27:43 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 4 Sep 2006 09:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-77) wrong parent object for
 nested model groups
In-Reply-To: <13844019.1154942652342.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10597969.1157376463879.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-77?page=all ]

Alexey Loubyansky closed JBXB-77.
---------------------------------

    Resolution: Done

Fixed.

> wrong parent object for nested model groups
> -------------------------------------------
>
>                 Key: JBXB-77
>                 URL: http://jira.jboss.com/jira/browse/JBXB-77
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0
>
>
> In the current impl If the model group binding is used then the parent object for a model group on the stack that will be the object created for the last element on the stack. Even if the parent of the model group is another model group.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:25:43 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 4 Sep 2006 10:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-81) DTDMarshaller:
 redundant
 startElement call for complex elements with character content
Message-ID: <4958400.1157379943792.JavaMail.jira@cloud.prod.atl2.jboss.com>

DTDMarshaller: redundant startElement call for complex elements with character content
--------------------------------------------------------------------------------------

                 Key: JBXB-81
                 URL: http://jira.jboss.com/jira/browse/JBXB-81
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
    Affects Versions: JBossXB-1.0.0.CR6
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky
             Fix For: JBossXB-1.0


Characters content of an element with mixed content will appear in a child element with the same name as the element being marshalled.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:27:46 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 10:27:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-292) Deadlock
In-Reply-To: <556149.1157029098201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10616007.1157380066885.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-292?page=comments#action_12342747 ] 
            
Bela Ban commented on JGRP-292:
-------------------------------

The deadlock was fixed by
- converting synchronized(mutex) into a EDU.util.concurrent.CondVar and ReentrantLock
- releasing the lock while sending the credit request and re-acquiring it afterwards

The code in FC looks a bit ugly, but with JDK 5's util.concurrent.lock.ReentrantLock/Condition, the lock() and unlock() methods will not have to be guarded by a try-catch clause (uninterruptible).

> Deadlock
> --------
>
>                 Key: JGRP-292
>                 URL: http://jira.jboss.com/jira/browse/JGRP-292
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Critical
>             Fix For: 2.4
>
>
> Stack dump shows deadlock:
> Name: http-192.168.5.2-8180-5
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 35,522  Total waited: 401
> Stack trace: 
> java.lang.Object.wait(Native Method)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:360)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: http-192.168.5.2-8180-4
> State: BLOCKED on org.jgroups.protocols.UNICAST$Entry at 13e6987 owned by: IncomingPacketHandler (channel=Tomcat-Cluster)
> Total blocked: 39,178  Total waited: 490
> Stack trace: 
> org.jgroups.protocols.UNICAST.down(UNICAST.java:264)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:283)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.GMS.down(GMS.java:809)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FC.sendCreditRequest(FC.java:528)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:365)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: IncomingPacketHandler (channel=Tomcat-Cluster)
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 85,549  Total waited: 18,813
> Stack trace: 
> org.jgroups.protocols.FC.handleCredit(FC.java:462)
> org.jgroups.protocols.FC.up(FC.java:319)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.GMS.up(GMS.java:753)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:773)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:471)
> org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:185)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD.up(FD.java:274)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:303)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.Discovery.up(Discovery.java:225)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.TP.handleIncomingMessage(TP.java:918)
> org.jgroups.protocols.TP.handleIncomingPacket(TP.java:860)
> org.jgroups.protocols.TP.access$200(TP.java:45)
> org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1294)
> java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:27:46 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 4 Sep 2006 10:27:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-81) DTDMarshaller: redundant
 startElement call for complex elements with character content
In-Reply-To: <4958400.1157379943792.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5742847.1157380067000.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-81?page=all ]

Alexey Loubyansky closed JBXB-81.
---------------------------------

    Resolution: Done

Fixed.

> DTDMarshaller: redundant startElement call for complex elements with character content
> --------------------------------------------------------------------------------------
>
>                 Key: JBXB-81
>                 URL: http://jira.jboss.com/jira/browse/JBXB-81
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0
>
>
> Characters content of an element with mixed content will appear in a child element with the same name as the element being marshalled.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 10:27:47 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 4 Sep 2006 10:27:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-292) Deadlock
In-Reply-To: <556149.1157029098201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24657521.1157380067135.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-292?page=all ]

Bela Ban resolved JGRP-292.
---------------------------

    Resolution: Done

Tested on both local laptop and ATL cluster lab, with 80M messages, no deadlocks

> Deadlock
> --------
>
>                 Key: JGRP-292
>                 URL: http://jira.jboss.com/jira/browse/JGRP-292
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Critical
>             Fix For: 2.4
>
>
> Stack dump shows deadlock:
> Name: http-192.168.5.2-8180-5
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 35,522  Total waited: 401
> Stack trace: 
> java.lang.Object.wait(Native Method)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:360)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: http-192.168.5.2-8180-4
> State: BLOCKED on org.jgroups.protocols.UNICAST$Entry at 13e6987 owned by: IncomingPacketHandler (channel=Tomcat-Cluster)
> Total blocked: 39,178  Total waited: 490
> Stack trace: 
> org.jgroups.protocols.UNICAST.down(UNICAST.java:264)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:283)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.GMS.down(GMS.java:809)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FC.sendCreditRequest(FC.java:528)
> org.jgroups.protocols.FC.handleDownMessage(FC.java:365)
> org.jgroups.protocols.FC.down(FC.java:300)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.protocols.FC.receiveDownEvent(FC.java:294)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.FRAG2.down(FRAG2.java:167)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.Protocol.passDown(Protocol.java:551)
> org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:276)
> org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
> org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:385)
> org.jgroups.JChannel.down(JChannel.java:1175)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:776)
> org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.passDown(MessageDispatcher.java:753)
> org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:286)
> org.jgroups.blocks.GroupRequest.doExecute(GroupRequest.java:439)
> org.jgroups.blocks.GroupRequest.execute(GroupRequest.java:189)
> org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:424)
> org.jgroups.blocks.RpcDispatcher.callRemoteMethods(RpcDispatcher.java:178)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4160)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4114)
> org.jboss.cache.TreeCache.callRemoteMethods(TreeCache.java:4215)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:110)
> org.jboss.cache.interceptors.BaseRpcInterceptor.replicateCall(BaseRpcInterceptor.java:88)
> org.jboss.cache.interceptors.ReplicationInterceptor.handleReplicatedMethod(ReplicationInterceptor.java:114)
> org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:83)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:167)
> org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> org.jboss.cache.TreeCache.put(TreeCache.java:3601)
> sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> java.lang.reflect.Method.invoke(Method.java:585)
> org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:279)
> org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> $Proxy58.put(Unknown Source)
> org.jboss.web.tomcat.tc5.session.JBossCacheWrapper.put(JBossCacheWrapper.java:141)
> org.jboss.web.tomcat.tc5.session.JBossCacheService.putSession(JBossCacheService.java:315)
> org.jboss.web.tomcat.tc5.session.JBossCacheClusteredSession.processSessionRepl(JBossCacheClusteredSession.java:122)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.processSessionRepl(JBossCacheManager.java:1094)
> org.jboss.web.tomcat.tc5.session.JBossCacheManager.storeSession(JBossCacheManager.java:649)
> org.jboss.web.tomcat.tc5.session.InstantSnapshotManager.snapshot(InstantSnapshotManager.java:49)
> org.jboss.web.tomcat.tc5.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:98)
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:153)
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> java.lang.Thread.run(Thread.java:595)
> Name: IncomingPacketHandler (channel=Tomcat-Cluster)
> State: BLOCKED on java.lang.Object at 2afbf7 owned by: http-192.168.5.2-8180-4
> Total blocked: 85,549  Total waited: 18,813
> Stack trace: 
> org.jgroups.protocols.FC.handleCredit(FC.java:462)
> org.jgroups.protocols.FC.up(FC.java:319)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.GMS.up(GMS.java:753)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:773)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:258)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:471)
> org.jgroups.protocols.UNICAST.up(UNICAST.java:206)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:569)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:185)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD.up(FD.java:274)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:303)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.Discovery.up(Discovery.java:225)
> org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
> org.jgroups.stack.Protocol.passUp(Protocol.java:538)
> org.jgroups.protocols.TP.handleIncomingMessage(TP.java:918)
> org.jgroups.protocols.TP.handleIncomingPacket(TP.java:860)
> org.jgroups.protocols.TP.access$200(TP.java:45)
> org.jgroups.protocols.TP$IncomingPacketHandler.run(TP.java:1294)
> java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 11:11:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Mon, 4 Sep 2006 11:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-759) Create a set of
 deadlock-detecting unit tests
Message-ID: <24324626.1157382703762.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create a set of deadlock-detecting unit tests
---------------------------------------------

                 Key: JBCACHE-759
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-759
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.0


>From email thread:

"Okay, found out that jconsole also supports it:
MBeans --> java.lang --> Threading --> Operations --> findMonitorDeadlockedThreads().

Of course, if we could integrate this into our test suites to regularly check for deadlocks..."

Article from JavaSpecialists:

    http://www.javaspecialists.co.za/archive/newsletter.do?issue=130&locale=en_US

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 11:41:47 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Mon, 4 Sep 2006 11:41:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-105) Make this JSF
 based system work on JBoss Portal 2.4
In-Reply-To: <7238225.1153926131402.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27784904.1157384507036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-105?page=all ]

Ryszard Kozmik reassigned JBFORUMS-105:
---------------------------------------

    Assignee: Ryszard Kozmik  (was: Sohil Shah)

> Make this JSF based system work on JBoss Portal 2.4
> ---------------------------------------------------
>
>                 Key: JBFORUMS-105
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-105
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>
> Investigate what need to be done to make this work on JBoss Portal 2.4
> Currently supported Portal version = 2.2.1RC1

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 12:01:43 2006
From: jira-events at jboss.com (bugra uytun (JIRA))
Date: Mon, 4 Sep 2006 12:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
In-Reply-To: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21309197.1157385703947.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-359?page=comments#action_12342753 ] 
            
bugra uytun commented on JBIDE-359:
-----------------------------------

After reading your comment I noticed that I wasn't precise enough and left room for misunderstanding, so I would like to explain it in more detail.

My DB (Apache Derby 10.1) uses as default schema "APP" but the tables I need are in "mySchema" schema where also the table "MY_TABLE" resides. To get the correct schema and the tables I needed to define the "hibernate.default_schema" property in .cfg.xml file - this doesn't mean that this must be the same default schema in my DB. But since the reverse engineered automagically generated .hbm.xml files do not contain the "schema" attribute hibernate tries to find the tables in the default schema - in this case in "APP" but this schema does not have such a table.

To get the correct table from correct schema I have to add the "schema" attribute to all generated .hbm.xml files by hand or I have to set he default schema on my DB to what I need - in this case to "mySchema".

I hope that I could clarify my position and I would appreciate if you reconsider this bug/whish list/etc. In case that I'm missing an already existing feature/checkbox/etc. I would be happy to use this and sorry for the annoyance.


> hibernate reverse engineering does not set "schema" attribute in .hbm.xml
> -------------------------------------------------------------------------
>
>                 Key: JBIDE-359
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>
> i set the schema in hibernate.cfg.xml with:
> ---
> <property name="hibernate.default_schema">mySchema</property>
> ---
> after reverse engineering the DB I get the .hbm.xml file
> ---
> ...
> <hibernate-mapping>
>     <class name="com.someclass" table="MY_TABLE">
> ...
> ---
> notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:
> ---
> org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
> ---

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 12:13:43 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Mon, 4 Sep 2006 12:13:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-359) hibernate reverse
 engineering does not set "schema" attribute in .hbm.xml
In-Reply-To: <32546966.1157316464033.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30165276.1157386423845.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-359?page=comments#action_12342755 ] 
            
Max Andersen commented on JBIDE-359:
------------------------------------

you should use the tools forum for these things in the future before reporting features as bugs ;)

look at <schema-selection> and if that doesn't help ask on forum.hibernate.org

> hibernate reverse engineering does not set "schema" attribute in .hbm.xml
> -------------------------------------------------------------------------
>
>                 Key: JBIDE-359
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-359
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Hibernate Tools
>         Environment: windows xp, eclipse 3.2, hibernate tools 3.2.0.b7
>            Reporter: bugra uytun
>         Assigned To: Max Andersen
>
> i set the schema in hibernate.cfg.xml with:
> ---
> <property name="hibernate.default_schema">mySchema</property>
> ---
> after reverse engineering the DB I get the .hbm.xml file
> ---
> ...
> <hibernate-mapping>
>     <class name="com.someclass" table="MY_TABLE">
> ...
> ---
> notice the missing 'schema="mySchema"'. if you're not using the default DB schema without this attribute you will get the following error:
> ---
> org.springframework.jdbc.BadSqlGrammarException: Hibernate operation: could not load an entity: [com.someclass#1];
> ---

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 13:27:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 4 Sep 2006 13:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-666) Throw
 javax.ejb.ConcurrentAccessException when two threads access the same SFSB
 instance
In-Reply-To: <29278907.1153950371470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32785197.1157390863980.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-666?page=all ]

Carlo de Wolf reassigned EJBTHREE-666:
--------------------------------------

    Assignee: Carlo de Wolf

> Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-666
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> See section 4.13.3 of the EJB Core Contracts specification.
> I need this for Seam.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:45:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-680) Standard
 security domain for ejb3 deployments
In-Reply-To: <6594371.1154619131314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15735216.1157409944628.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-680?page=comments#action_12342776 ] 
            
William DeCoste commented on EJBTHREE-680:
------------------------------------------

EJB RC9 now supports use of the Properties Service for deployment descriptors - this provides this requested functionality.

> Standard security domain for ejb3 deployments
> ---------------------------------------------
>
>                 Key: EJBTHREE-680
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-680
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>
> The ejb3 container could provide an optional standard security domain that is used when a bean doesn't provide a SecurityDomain annotation. The ejb 2.x stack provides this feature already (in standarjboss.xml). 
> This feature is important in environments in which the same deployment is deployed into different JBoss servers (e.g a test JBoss instance may have another default security domain than production). 

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:45:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-680) Standard security
 domain for ejb3 deployments
In-Reply-To: <6594371.1154619131314.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14298304.1157409944810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-680?page=all ]

William DeCoste closed EJBTHREE-680.
------------------------------------

    Resolution: Done

> Standard security domain for ejb3 deployments
> ---------------------------------------------
>
>                 Key: EJBTHREE-680
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-680
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>
> The ejb3 container could provide an optional standard security domain that is used when a bean doesn't provide a SecurityDomain annotation. The ejb 2.x stack provides this feature already (in standarjboss.xml). 
> This feature is important in environments in which the same deployment is deployed into different JBoss servers (e.g a test JBoss instance may have another default security domain than production). 

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:49:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25007887.1157410183945.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=comments#action_12342777 ] 
            
William DeCoste commented on EJBTHREE-679:
------------------------------------------

EJB RC9 now supports use of the Properties Service for deployment descriptors - this provides this requested functionality. 

> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:49:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 18:49:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28911184.1157410184135.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=all ]

William DeCoste closed EJBTHREE-679.
------------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD
       Resolution: Done

> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 18:57:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Mon, 4 Sep 2006 18:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1018) Do not display
 edit mode when user is not logged in
Message-ID: <1888465.1157410663830.JavaMail.jira@cloud.prod.atl2.jboss.com>

Do not display edit mode when user is not logged in
---------------------------------------------------

                 Key: JBPORTAL-1018
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1018
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep  4 19:25:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 4 Sep 2006 19:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-628) Redeployment
 doesn't work with E-EJB3
Message-ID: <23868561.1157412344792.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-628?page=all ]

William DeCoste closed EJBTHREE-628.
------------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD
       Resolution: Done

> Redeployment doesn't work with E-EJB3
> -------------------------------------
>
>                 Key: EJBTHREE-628
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-628
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Christian Bauer
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I'm executing the following sequence:
> EJB3StandaloneBootstrap.boot(null);
> EJB3StandaloneBootstrap.deployXmlResource("META-INF/jboss-beans.xml");
> EJB3StandaloneDeployer deployer =  EJB3StandaloneBootstrap.createDeployer();
> deployer.getArchivesByResource().add("META-INF/persistence.xml");
> deployer.create();
> deployer.start();
> deployer.stop();
> deployer.destroy();
> deployer.create();
> deployer.start();
> This fails on the second start() with this:
> 12:34:17,397  INFO MCKernelAbstraction:84 - installing bean:  jboss.j2ee:jar=classes,name=PlaceItemBean,service=EJB3 with  dependencies:
> 12:34:17,399  INFO MCKernelAbstraction:87 -      AbstractDependencyMetaData at 44fc5e {dependency=persistence.units:jar=classes.jar,unitName=caveatemptorDatab ase}
> 12:34:17,688 ERROR AbstractKernelController:350 - Error installing to  Start: name=jboss.j2ee:jar=classes,name=PlaceItemBean,service=EJB3  state=Create
> javax.naming.NamingException: Could not bind user transaction for ejb  name PlaceItemBean into JNDI under jndiName: /UserTransaction [Root  exception is javax.naming.NameAlreadyBoundException]
>     at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:650)
>     at org.jboss.ejb3.EJBContainer.initializePool(EJBContainer.java:595)
>     at org.jboss.ejb3.EJBContainer.start(EJBContainer.java:526)
>     at org.jboss.ejb3.SessionContainer.start(SessionContainer.java:82)
>     at org.jboss.ejb3.stateful.StatefulContainer.start (StatefulContainer.java:73)
>     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.jboss.reflect.plugins.introspection.ReflectionUtils.invoke (ReflectionUtils.java:55)
>     at  org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke (ReflectMethodInfoImpl.java:107)
>     at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch (BasicMethodJoinPoint.java:66)
>     at  org.jboss.kernel.plugins.dependency.KernelControllerContextActions.dispa tchJoinPoint(KernelControllerContextActions.java:100)
>     at org.jboss.kernel.plugins.dependency.KernelControllerContextActions $LifecycleAction.installAction(KernelControllerContextActions.java:582)
>     at org.jboss.kernel.plugins.dependency.KernelControllerContextActions $KernelControllerContextAction.install (KernelControllerContextActions.java:175)
>     at  org.jboss.dependency.plugins.AbstractControllerContextActions.install (AbstractControllerContextActions.java:51)
>     at org.jboss.dependency.plugins.AbstractControllerContext.install (AbstractControllerContext.java:226)
>     at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:593)
>     at org.jboss.dependency.plugins.AbstractController.incrementState (AbstractController.java:346)
>     at org.jboss.dependency.plugins.AbstractController.resolveContexts (AbstractController.java:438)
>     at org.jboss.dependency.plugins.AbstractController.resolveContexts (AbstractController.java:379)
>     at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:225)
>     at org.jboss.dependency.plugins.AbstractController.install (AbstractController.java:151)
>     at  org.jboss.kernel.plugins.dependency.AbstractKernelController.install (AbstractKernelController.java:79)
>     at  org.jboss.kernel.plugins.dependency.AbstractKernelController.install (AbstractKernelController.java:73)
>     at org.jboss.ejb3.MCKernelAbstraction.install (MCKernelAbstraction.java:91)
>     at org.jboss.ejb3.Ejb3Deployment.registerEJBContainer (Ejb3Deployment.java:439)
>     at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:486)
>     at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.start (EJB3StandaloneDeployer.java:460)
>     at org.hibernate.ce.auction.test.runtime.IntegrationTest.cleanup (IntegrationTest.java:73)
>     at org.hibernate.ce.auction.test.foo.TestOne.afterTest(TestOne.java:18)
>     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.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:552)
>     at org.testng.internal.Invoker.invokeConfigurationMethod (Invoker.java:318)
>     at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:152)
>     at org.testng.internal.Invoker.invokeMethod(Invoker.java:483)
>     at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:778)
>     at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:105)
>     at org.testng.TestRunner.privateRun(TestRunner.java:682)
>     at org.testng.TestRunner.run(TestRunner.java:566)
>     at org.testng.SuiteRunner.privateRun(SuiteRunner.java:220)
>     at org.testng.SuiteRunner.run(SuiteRunner.java:146)
>     at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:86)
>     at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:123)
> Caused by: javax.naming.NameAlreadyBoundException
>     at org.jnp.server.NamingServer.bind(NamingServer.java:144)
>     at org.jnp.interfaces.NamingContext.bind(NamingContext.java:567)
>     at org.jnp.interfaces.NamingContext.bind(NamingContext.java:532)
>     at org.jboss.util.naming.Util.bind(Util.java:102)
>     at org.jboss.util.naming.Util.bind(Util.java:89)
>     at org.jboss.ejb3.EJBContainer.resolveInjectors(EJBContainer.java:647)

-- 
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

        


From jira-events at jboss.com  Mon Sep  4 19:51:43 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Mon, 4 Sep 2006 19:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1018) Do not display
 edit mode when user is not logged in
In-Reply-To: <1888465.1157410663830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30014417.1157413903832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1018?page=all ]

Julien Viet resolved JBPORTAL-1018.
-----------------------------------

    Resolution: Done

> Do not display edit mode when user is not logged in
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1018
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1018
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From c9 at fullmailmarket.com  Tue Sep  5 00:10:45 2006
From: c9 at fullmailmarket.com (179.cl)
Date: Tue, 5 Sep 2006 00:10:45 -0400
Subject: [jboss-jira] DEFINTIVAMENTE LOS MEJORES PRECIOS PARA LLAMAR A CHILE
	Y AL EXTRANJERO :: CARRIER 179 :: OFERTA LANZAMIENTO
Message-ID: <200609050410.k854Aj8i012295@chief.dmz.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060905/76851988/attachment-0001.html 

From jira-events at jboss.com  Tue Sep  5 01:15:26 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Tue, 5 Sep 2006 01:15:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
Message-ID: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>

CLONE -Seam and Myfaces ajax support.
-------------------------------------

                 Key: JBSEAM-342
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
             Project: JBoss Seam
          Issue Type: Feature Request
         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
            Reporter: Sergei Rogovskiy


Hi,

I have tried to use seam and myfaces sandbox component InputSugestAjax.
 Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
Please verify this issue, Maibe in the feature will be a problem in integration.

Thanks,
Cristi

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 01:21:37 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Tue, 5 Sep 2006 01:21:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15873217.1157433697862.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12342793 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

I think there is an issue with SeamVariableResolver when AJAX bean tries to resolve variable at some point. In fact using standard variable resolver solves the problem.  I am getting a nullpointer which is pretty obviosly comes from Seam. Using standard variable resolver is not a workaround since it disables all seam features, so I think the issue is pretty big.

00:14:04,033 ERROR [MyFacesResourceLoader] Could not find the class for component org.apache.myfaces.custom.templates to load a resource.
00:14:05,861 ERROR [PhaseListenerManager] Exception in PhaseListener APPLY_REQUEST_VALUES(2) beforePhase.
javax.faces.el.EvaluationException: Exception while invoking expression #{cityAjaxBean.getItems}
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:165)
        at org.apache.myfaces.custom.suggestajax.SuggestAjaxRenderer.getSuggestedItems(SuggestAjaxRenderer.java:56)
        at org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjaxRenderer.encodeAjax(InputSuggestAjaxRenderer.java:149)
        at org.apache.myfaces.custom.suggestajax.SuggestAjax.encodeAjax(SuggestAjax.java:91)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.encodeAjax(AjaxDecodePhaseListener.java:210)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.handleAjaxRequest(AjaxDecodePhaseListener.java:121)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.beforePhase(AjaxDecodePhaseListener.java:99)
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
        at org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(LifecycleImpl.java:206)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
        at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.NullPointerException
        at org.jboss.seam.contexts.PageContext.getCurrentReadableMap(PageContext.java:62)
        at org.jboss.seam.contexts.PageContext.get(PageContext.java:52)
        at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:125)
        at org.jboss.seam.Component.getInstance(Component.java:1245)
        at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
        at org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.resolveVariable(RedirectTrackerVariableResolver.java:38)
        at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
        at org.apache.myfaces.el.ValueBindingImpl$ELVariableResolver.resolveVariable(ValueBindingImpl.java:567)
        at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124)
        at org.apache.myfaces.el.ValueBindingImpl.resolveToBaseAndProperty(ValueBindingImpl.java:455)
        at org.apache.myfaces.el.MethodBindingImpl.resolveToBaseAndProperty(MethodBindingImpl.java:180)
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:114)
        ... 31 more
00:14:06,157 ERROR [PhaseListenerManager] Exception in PhaseListener APPLY_REQUEST_VALUES(2) beforePhase.
javax.faces.el.EvaluationException: Exception while invoking expression #{cityAjaxBean.getItems}
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:165)
        at org.apache.myfaces.custom.suggestajax.SuggestAjaxRenderer.getSuggestedItems(SuggestAjaxRenderer.java:56)
        at org.apache.myfaces.custom.suggestajax.inputsuggestajax.InputSuggestAjaxRenderer.encodeAjax(InputSuggestAjaxRenderer.java:149)
        at org.apache.myfaces.custom.suggestajax.SuggestAjax.encodeAjax(SuggestAjax.java:91)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.encodeAjax(AjaxDecodePhaseListener.java:210)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.handleAjaxRequest(AjaxDecodePhaseListener.java:121)
        at org.apache.myfaces.custom.ajax.api.AjaxDecodePhaseListener.beforePhase(AjaxDecodePhaseListener.java:99)
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
        at org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(LifecycleImpl.java:206)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
        at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.NullPointerException
        at org.jboss.seam.contexts.PageContext.getCurrentReadableMap(PageContext.java:62)
        at org.jboss.seam.contexts.PageContext.get(PageContext.java:52)
        at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:125)
        at org.jboss.seam.Component.getInstance(Component.java:1245)
        at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
        at org.apache.myfaces.custom.redirectTracker.RedirectTrackerVariableResolver.resolveVariable(RedirectTrackerVariableResolver.java:38)
        at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
        at org.apache.myfaces.el.ValueBindingImpl$ELVariableResolver.resolveVariable(ValueBindingImpl.java:567)
        at org.apache.commons.el.NamedValue.evaluate(NamedValue.java:124)
        at org.apache.myfaces.el.ValueBindingImpl.resolveToBaseAndProperty(ValueBindingImpl.java:455)
        at org.apache.myfaces.el.MethodBindingImpl.resolveToBaseAndProperty(MethodBindingImpl.java:180)
        at org.apache.myfaces.el.MethodBindingImpl.invoke(MethodBindingImpl.java:114)
        ... 31 more

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 01:21:37 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Tue, 5 Sep 2006 01:21:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10240756.1157433698004.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12342794 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

The same thing described here: http://mail-archives.apache.org/mod_mbox/myfaces-users/200603.mbox/%3Cdvrahn$a20$1 at sea.gmane.org%3E

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 05:52:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 5 Sep 2006 05:52:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3463) Loading of
 persisted XMBean attributes does not work for custom types
In-Reply-To: <10889960.1154635811842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10065977.1157449953808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3463?page=all ]

Dimitris Andreadis reassigned JBAS-3463:
----------------------------------------

    Assignee: Dimitris Andreadis

> Loading of persisted XMBean attributes does not work for custom types
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3463
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3463
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> When using XMBean persistence for a complex attribute (my own type), all seems to go well when changes are persisted/serialized, but when the XMBean is redeployed (and its persisted state is read), there are problems unserializing the serialized data
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar -> C:\Java\jboss-4.0.4\server\test\tmp\deploy\tmp7332examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.SARDeployer at 153c375
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] about to copy 0 local directories
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, create step: url file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Registering service UCL=jmx.loading:UCL=46fef3
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.ServiceCreator] About to create xmbean object: example:service=ExampleService with code: example.ExampleService with embedded descriptor
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Loaded persistence mgr: org.jboss.mx.persistence.DelegatingPersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] init() --- ModelMBeanInfo Descriptor ---
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] descriptorType=mbean, displayName=org.jboss.mx.modelmbean.XMBean, log=F, name=org.jboss.mx.modelmbean.XMBean, objectname=(example:service=ExampleService), persistence-manager=org.jboss.mx.persistence.DelegatingPersistenceManager, persistPolicy=OnUpdate, resourceClass=example.ExampleService, visibility=1
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] chosen persistent id: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] using AttributePersistenceManager: org.jboss.system.pm.XMLAttributePersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] load() called for: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.pm.XMLAttributePersistenceManager] load(example:service=ExampleService)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.system.pm.XMLAttributePersistenceManager] Cannot deserialize object
> java.lang.ClassNotFoundException: example.ComplexAttribute
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584)
>     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
>     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
>     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
>     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.decodeFromHexString(XMLAttributePersistenceManager.java:738)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:440)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.persistence.DelegatingPersistenceManager] Caught exception while loading
> java.lang.Exception: Failed to deserialize attribute 'SomeAttribute'
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:443)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.server.registry.BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='example:service=ExampleService', Class=example.ExampleService (example.ExampleService at ae8af4)]
> 2006-08-01 14:33:59,329 INFO  [example.ExampleService] Registration is not done -> stop
> .

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 06:44:29 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 5 Sep 2006 06:44:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
Message-ID: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>

TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
--------------------------------------------------------------------------

                 Key: JBCACHE-760
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
    Affects Versions: 1.4.0.SP1
            Reporter: Nitzan Niv
         Assigned To: Manik Surtani


In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.

java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
	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:324)
	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)

To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:

   public void testNodeCreatedAndModifiedMapEvent() throws Exception {
       EventLog el = new EventLog(cache);
       cache.addTreeCacheListener(el);
       Map data = new HashMap();
       data.put("key", "value");
       cache.putObject("/hello/world", data);
       ...
  }

 and the relevant listener code:

      public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
         events.add("modify "+
                 (pre? "about to modify " : "Modified ") +
                 (isLocal? "local " : "remote ") + fqn);
		 if(this.cache != null && !pre) {
			try {
				cache.getObject(fqn);
			}
			catch (Exception e) {
				events.add(e);
                e.printStackTrace(System.err);
			}
		 }
      }


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 07:44:24 2006
From: jira-events at jboss.com (Doug Palmer (JIRA))
Date: Tue, 5 Sep 2006 07:44:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBJMX-100) Class loader doesn't
 contain classes from MBean jar file when the MBean is redeployed.
Message-ID: <8749254.1157456665009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Class loader doesn't contain classes from MBean jar file when the MBean is redeployed.
--------------------------------------------------------------------------------------

                 Key: JBJMX-100
                 URL: http://jira.jboss.com/jira/browse/JBJMX-100
             Project: JBoss JMX
          Issue Type: Bug
    Affects Versions: JBossAS-4.0.0
         Environment: Mac OSX and Windows XP
            Reporter: Doug Palmer


This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".

To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".

If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 07:46:25 2006
From: jira-events at jboss.com (Doug Palmer (JIRA))
Date: Tue, 5 Sep 2006 07:46:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJMX-100) Class loader doesn't
 contain classes from MBean jar file when the MBean is redeployed.
In-Reply-To: <8749254.1157456665009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30824154.1157456785109.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBJMX-100?page=all ]

Doug Palmer updated JBJMX-100:
------------------------------

    Attachment: RedeployBug.zip

jboss.home and jboss.profile should be changed to reflect your jboss installation.

> Class loader doesn't contain classes from MBean jar file when the MBean is redeployed.
> --------------------------------------------------------------------------------------
>
>                 Key: JBJMX-100
>                 URL: http://jira.jboss.com/jira/browse/JBJMX-100
>             Project: JBoss JMX
>          Issue Type: Bug
>    Affects Versions: JBossAS-4.0.0
>         Environment: Mac OSX and Windows XP
>            Reporter: Doug Palmer
>         Attachments: RedeployBug.zip
>
>
> This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".
> To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".
> If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 07:50:24 2006
From: jira-events at jboss.com (Doug Palmer (JIRA))
Date: Tue, 5 Sep 2006 07:50:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBJMX-100) Class loader doesn't
 contain classes from MBean jar file when the MBean is redeployed.
In-Reply-To: <8749254.1157456665009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9271769.1157457024329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBJMX-100?page=all ]

Doug Palmer updated JBJMX-100:
------------------------------

    Description: 
This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".  Oddly, a properties file from the package is located successfully before the class loader fails.

To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".

If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

  was:
This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".

To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".

If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.


> Class loader doesn't contain classes from MBean jar file when the MBean is redeployed.
> --------------------------------------------------------------------------------------
>
>                 Key: JBJMX-100
>                 URL: http://jira.jboss.com/jira/browse/JBJMX-100
>             Project: JBoss JMX
>          Issue Type: Bug
>    Affects Versions: JBossAS-4.0.0
>         Environment: Mac OSX and Windows XP
>            Reporter: Doug Palmer
>         Attachments: RedeployBug.zip
>
>
> This is a simplified version of a Deployer MBean that I have been writing.  The MBean uses some jaxb generated classes.  When the MBean is first deployed it's create method functions perfectly.  However, if the MBean is redeployed then calling create fails because the class loader can't find the package "decs2.process_definition".  Oddly, a properties file from the package is located successfully before the class loader fails.
> To replicate the problem execute the ant target named "deploy-all"; then run JBoss; then execute the ant target named "deploy".
> If the package "decs2.process_definition" is is placed in a seperate jar file and that jar file is placed in the server/lib directory then the MBean redeploys successfully.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:02:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-473) RuleItem: need to
 have URI+content not LHS/RHS
Message-ID: <26846113.1157457745377.JavaMail.jira@cloud.prod.atl2.jboss.com>

RuleItem: need to have URI+content not LHS/RHS
----------------------------------------------

                 Key: JBRULES-473
                 URL: http://jira.jboss.com/jira/browse/JBRULES-473
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:02:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-473) RuleItem: need
 to have URI+content not LHS/RHS
In-Reply-To: <26846113.1157457745377.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22512229.1157457745506.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-473?page=comments#action_12342802 ] 
            
Michael Neale commented on JBRULES-473:
---------------------------------------

Will be able to store normalised stuff when parsing out (so will need some extra fields in future for searching).

> RuleItem: need to have URI+content not LHS/RHS
> ----------------------------------------------
>
>                 Key: JBRULES-473
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-473
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:02:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:02:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-420) rule storage:
	more normalised
In-Reply-To: <9873733.1155586697372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16743775.1157457745652.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-420?page=all ]

Michael Neale resolved JBRULES-420.
-----------------------------------

    Resolution: Done

> rule storage: more normalised
> -----------------------------
>
>                 Key: JBRULES-420
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-420
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> At the moment, its just a blob.
> But I think it should be:
> name
> attribute map
> LHS
> RHS
> meta-data (perhaps seperate node - dublin core stuff).

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:04:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:04:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-474) RulePackage to
 have RuleItem as child
Message-ID: <24868883.1157457865012.JavaMail.jira@cloud.prod.atl2.jboss.com>

RulePackage to have RuleItem as child
-------------------------------------

                 Key: JBRULES-474
                 URL: http://jira.jboss.com/jira/browse/JBRULES-474
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:04:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:04:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-465) scalability test
In-Reply-To: <3411872.1156952866490.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32068711.1157457865160.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-465?page=all ]

Michael Neale resolved JBRULES-465.
-----------------------------------

    Resolution: Done

> scalability test
> ----------------
>
>                 Key: JBRULES-465
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-465
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> Need to sumulate:
> 5000 rules
> 5 X 5 X 5 categories (rules spread evenly)
> 10 packages (rules spread evenly)
> To time: retrieval for a category
> retrieval for a package
> time to update a rule
> time to retrieve a rule

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:06:25 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 5 Sep 2006 08:06:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-462) Package Update
	feature
In-Reply-To: <27828061.1156925503892.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12441466.1157457985996.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-462?page=comments#action_12342803 ] 
            
Michael Neale commented on JBRULES-462:
---------------------------------------

this can perhaps be done better, as the package just has a reference to a rule, and we 
"query" out the rules based on the status on request. (by default always looking at HEAD?)

> Package Update feature
> ----------------------
>
>                 Key: JBRULES-462
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-462
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> as packages have references to rules, when a rule is changed/updated, need to have a method to update packages to use the appropriate version of the rule.
> I would expect that most of the time, a package will only want to be updated when a rule status is changed to "production" for instance.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:08:25 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Tue, 5 Sep 2006 08:08:25 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-653) No pooling for
 stateless session beans
In-Reply-To: <12321988.1153207692016.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22611851.1157458105786.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-653?page=all ]

Carlo de Wolf resolved EJBTHREE-653.
------------------------------------

    Fix Version/s: EJB 3.0 RC9 - FD
       Resolution: Cannot Reproduce Bug

> No pooling for stateless session beans
> --------------------------------------
>
>                 Key: EJBTHREE-653
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-653
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: OS: Windows XP SP2
> JDK 1.5.0_06_b05
> JBoss AS 4.0.4 GA
>            Reporter: Guido Bening
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Scenario:
> Client VM calls a method on a EJB 2 Stateful Session Bean (SFSB) via the remote interface in a loop for 1000 times.Transaction starts on the application server. The SFSB method calls a method on a EJB3 Stateless Session Bean (SLSB) - via the remote interface (local interface makes no difference).
> The print out in the PostConstruct callback method of the EJB3 SLSB shows us, that a new bean instance was created for each of the 1000 method calls. Because of ThreadLocal pooling approach, we print out the Thread id too to show, that we always have the same Thread for each method call.
> CallBack method:
>     /**
>      * EJBCreate method.
>      */
>     @PostConstruct
>     public void ejb3Create() {
>         System.out.println("New SessionBean " + this);
>         System.out.println("Thread " + Thread.currentThread().getId());
>         setupBean();
>     }
>     
> And the log for a few of the 1000 calls:
> ...
> 09:17:51,119 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 231ae2
> 09:17:51,129 INFO  [STDOUT] Thread 97
> 09:17:51,139 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1662174
> 09:17:51,139 INFO  [STDOUT] Thread 97
> 09:17:51,219 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 189f155
> 09:17:51,219 INFO  [STDOUT] Thread 97
> 09:17:51,239 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a82dfb
> 09:17:51,239 INFO  [STDOUT] Thread 97
> 09:17:51,289 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 198813a
> 09:17:51,289 INFO  [STDOUT] Thread 97
> 09:17:51,309 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 59eefd
> 09:17:51,309 INFO  [STDOUT] Thread 97
> 09:17:51,359 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 2e3520
> 09:17:51,369 INFO  [STDOUT] Thread 97
> 09:17:51,379 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1ed457
> 09:17:51,379 INFO  [STDOUT] Thread 97
> 09:17:51,439 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1e1c7f3
> 09:17:51,439 INFO  [STDOUT] Thread 97
> 09:17:51,449 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 15cb8ed
> 09:17:51,449 INFO  [STDOUT] Thread 97
> 09:17:51,519 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 1a4a949
> 09:17:51,519 INFO  [STDOUT] Thread 97
> 09:17:51,529 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19ae0a
> 09:17:51,529 INFO  [STDOUT] Thread 97
> 09:17:51,589 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 567fa0
> 09:17:51,599 INFO  [STDOUT] Thread 97
> 09:17:51,609 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 19956fe
> 09:17:51,609 INFO  [STDOUT] Thread 97
> 09:17:51,659 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at 150e574
> 09:17:51,669 INFO  [STDOUT] Thread 97
> 09:17:51,679 INFO  [STDOUT] New SessionBean com.jcoffee.components.um3.UserManagementComponent3 at aa46ad
> 09:17:51,679 INFO  [STDOUT] Thread 97
> ...

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:12:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 5 Sep 2006 08:12:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3463) Loading of persisted
 XMBean attributes does not work for custom types
In-Reply-To: <10889960.1154635811842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26509391.1157458354345.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3463?page=all ]

Dimitris Andreadis updated JBAS-3463:
-------------------------------------

        Fix Version/s: JBossAS-5.0.0.Beta
                       JBossAS-3.2.8.SP2
    Affects Version/s: JBossAS-3.2.8.SP1

> Loading of persisted XMBean attributes does not work for custom types
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3463
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3463
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> When using XMBean persistence for a complex attribute (my own type), all seems to go well when changes are persisted/serialized, but when the XMBean is redeployed (and its persisted state is read), there are problems unserializing the serialized data
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar -> C:\Java\jboss-4.0.4\server\test\tmp\deploy\tmp7332examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.SARDeployer at 153c375
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] about to copy 0 local directories
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, create step: url file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Registering service UCL=jmx.loading:UCL=46fef3
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.ServiceCreator] About to create xmbean object: example:service=ExampleService with code: example.ExampleService with embedded descriptor
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Loaded persistence mgr: org.jboss.mx.persistence.DelegatingPersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] init() --- ModelMBeanInfo Descriptor ---
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] descriptorType=mbean, displayName=org.jboss.mx.modelmbean.XMBean, log=F, name=org.jboss.mx.modelmbean.XMBean, objectname=(example:service=ExampleService), persistence-manager=org.jboss.mx.persistence.DelegatingPersistenceManager, persistPolicy=OnUpdate, resourceClass=example.ExampleService, visibility=1
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] chosen persistent id: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] using AttributePersistenceManager: org.jboss.system.pm.XMLAttributePersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] load() called for: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.pm.XMLAttributePersistenceManager] load(example:service=ExampleService)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.system.pm.XMLAttributePersistenceManager] Cannot deserialize object
> java.lang.ClassNotFoundException: example.ComplexAttribute
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584)
>     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
>     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
>     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
>     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.decodeFromHexString(XMLAttributePersistenceManager.java:738)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:440)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.persistence.DelegatingPersistenceManager] Caught exception while loading
> java.lang.Exception: Failed to deserialize attribute 'SomeAttribute'
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:443)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.server.registry.BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='example:service=ExampleService', Class=example.ExampleService (example.ExampleService at ae8af4)]
> 2006-08-01 14:33:59,329 INFO  [example.ExampleService] Registration is not done -> stop
> .

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:12:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 5 Sep 2006 08:12:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3463) Loading of persisted
 XMBean attributes does not work for custom types
In-Reply-To: <10889960.1154635811842.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28752093.1157458354702.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3463?page=all ]

Dimitris Andreadis closed JBAS-3463.
------------------------------------

    Resolution: Done

Should be fixed now, see
org.jboss.test.jmx.test.XMLAttributePersistenceManagerUnitTestCase

> Loading of persisted XMBean attributes does not work for custom types
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3463
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3463
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>
> When using XMBean persistence for a complex attribute (my own type), all seems to go well when changes are persisted/serialized, but when the XMBean is redeployed (and its persisted state is read), there are problems unserializing the serialized data
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar -> C:\Java\jboss-4.0.4\server\test\tmp\deploy\tmp7332examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.SARDeployer at 153c375
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] about to copy 0 local directories
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] looking for nested deployments in : file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 12a3722, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 46fef3{ url=file:/C:/Java/jboss-4.0.4/server/test/tmp/deploy/tmp7332examplexmbean.sar ,addedOrder=0}
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.MainDeployer] create step for deployment file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, create step: url file:/C:/Documents and Settings/jiwils/Desktop/examplexmbean/dist/examplexmbean.sar
> 2006-08-01 14:33:59,314 DEBUG [org.jboss.deployment.SARDeployer] Registering service UCL=jmx.loading:UCL=46fef3
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.ServiceCreator] About to create xmbean object: example:service=ExampleService with code: example.ExampleService with embedded descriptor
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Loaded persistence mgr: org.jboss.mx.persistence.DelegatingPersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] init() --- ModelMBeanInfo Descriptor ---
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] descriptorType=mbean, displayName=org.jboss.mx.modelmbean.XMBean, log=F, name=org.jboss.mx.modelmbean.XMBean, objectname=(example:service=ExampleService), persistence-manager=org.jboss.mx.persistence.DelegatingPersistenceManager, persistPolicy=OnUpdate, resourceClass=example.ExampleService, visibility=1
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] chosen persistent id: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] using AttributePersistenceManager: org.jboss.system.pm.XMLAttributePersistenceManager
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.mx.persistence.DelegatingPersistenceManager] load() called for: 'example:service=ExampleService'
> 2006-08-01 14:33:59,329 DEBUG [org.jboss.system.pm.XMLAttributePersistenceManager] load(example:service=ExampleService)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.system.pm.XMLAttributePersistenceManager] Cannot deserialize object
> java.lang.ClassNotFoundException: example.ComplexAttribute
>     at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>     at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:242)
>     at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584)
>     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543)
>     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465)
>     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698)
>     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304)
>     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.decodeFromHexString(XMLAttributePersistenceManager.java:738)
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:440)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.persistence.DelegatingPersistenceManager] Caught exception while loading
> java.lang.Exception: Failed to deserialize attribute 'SomeAttribute'
>     at org.jboss.system.pm.XMLAttributePersistenceManager.load(XMLAttributePersistenceManager.java:443)
>     at org.jboss.mx.persistence.DelegatingPersistenceManager.load(DelegatingPersistenceManager.java:98)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.load(ModelMBeanInvoker.java:411)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:523)
>     at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
>     at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
>     at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211)
>     at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
>     at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1350)
>     at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345)
>     at org.jboss.system.ServiceCreator.install(ServiceCreator.java:181)
>     at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449)
>     at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171)
>     at org.jboss.system.ServiceController.install(ServiceController.java:226)
>     at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>     at $Proxy4.install(Unknown Source)
>     at org.jboss.deployment.SARDeployer.create(SARDeployer.java:249)
>     at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
>     at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>     at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:585)
>     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
>     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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>     at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:819)
>     at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:420)
>     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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>     at sun.rmi.transport.Transport$1.run(Transport.java:153)
>     at java.security.AccessController.doPrivileged(Native Method)
>     at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>     at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
>     at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
>     at java.lang.Thread.run(Thread.java:595)
> 2006-08-01 14:33:59,329 WARN  [org.jboss.mx.server.registry.BasicMBeanRegistry] javax.management.MBeanRegistrationException: preRegister() failed: [ObjectName='example:service=ExampleService', Class=example.ExampleService (example.ExampleService at ae8af4)]
> 2006-08-01 14:33:59,329 INFO  [example.ExampleService] Registration is not done -> stop
> .

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 08:18:28 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Tue, 5 Sep 2006 08:18:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-697) First concurrent
 call doesn't throw exception
Message-ID: <23214189.1157458708176.JavaMail.jira@cloud.prod.atl2.jboss.com>

First concurrent call doesn't throw exception
---------------------------------------------

                 Key: EJBTHREE-697
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-697
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: Carlo de Wolf
            Priority: Critical
             Fix For: EJB 3.0 RC10 - FD


Concurrency check is in the server interceptor, while identity is established in the proxy after the first call. So if the first call is concurrent no exception is thrown. (see unit test concurrent)

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 10:48:29 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Tue, 5 Sep 2006 10:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1019)
 NoClassDefFoundError does not show up during portlet access
Message-ID: <29790682.1157467709772.JavaMail.jira@cloud.prod.atl2.jboss.com>

NoClassDefFoundError does not show up during portlet access
-----------------------------------------------------------

                 Key: JBPORTAL-1019
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1019
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 11:56:33 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Tue, 5 Sep 2006 11:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-748) Make
 JdbmCacheLoader use the
 standard binary format for persistent state transfer
In-Reply-To: <20953458.1156632011518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17175644.1157471793036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-748?page=all ]

Vladimir Blagojevic resolved JBCACHE-748.
-----------------------------------------

    Resolution: Done

> Make JdbmCacheLoader use the standard binary format for persistent state transfer
> ---------------------------------------------------------------------------------
>
>                 Key: JBCACHE-748
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-748
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>            Reporter: Brian Stansberry
>             Fix For: 2.0.0
>
>
> The state should be a sequence of NodeData objects; see FileCacheLoader or JDBCCacheLoader.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 11:56:33 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Tue, 5 Sep 2006 11:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1019)
 NoClassDefFoundError does not show up during portlet access
In-Reply-To: <29790682.1157467709772.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27993859.1157471793243.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1019?page=all ]

Julien Viet resolved JBPORTAL-1019.
-----------------------------------

    Resolution: Done

> NoClassDefFoundError does not show up during portlet access
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1019
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1019
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 12:36:33 2006
From: jira-events at jboss.com (Ruel Loehr (JIRA))
Date: Tue, 5 Sep 2006 12:36:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <534788.1157474193376.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342834 ] 
            
Ruel Loehr commented on JBAS-3345:
----------------------------------

Tested this locally.  I removed the thirdparty tomcat dependencies and replaced them with jbossweb.   It is buildable.  Should be ready to changeover in the code and then address any testsuite issues.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 13:17:32 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 13:17:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-1) Move source
 repository from trunk to projects
Message-ID: <2995519.1157476652735.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move source repository from trunk to projects
---------------------------------------------

                 Key: SECURITY-1
                 URL: http://jira.jboss.com/jira/browse/SECURITY-1
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Repository
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Scott has expressed a desire to see the security project act as the model project to have a SPI and a JBossAS implementation. 

The first step in this exercize is to move the source repository from jbossas/trunk  to https://svn.jboss.org/repos/jbossas/projects/  (Reference will be the microcontainer project)



-- 
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

        


From jira-events at jboss.com  Tue Sep  5 13:43:28 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 13:43:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-2) Security Jars Into
 Thirdparty Repository
Message-ID: <27229725.1157478208545.JavaMail.jira@cloud.prod.atl2.jboss.com>

Security Jars Into Thirdparty Repository
----------------------------------------

                 Key: SECURITY-2
                 URL: http://jira.jboss.com/jira/browse/SECURITY-2
             Project: JBoss Security
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Repository
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


The JBoss Security Jars should be available via the thirdparty repository.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 14:25:30 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 14:25:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-2) Security Jars Into
 Thirdparty Repository
In-Reply-To: <27229725.1157478208545.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18850614.1157480730039.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-2?page=all ]

Anil Saldhana closed SECURITY-2.
--------------------------------

    Resolution: Done

jboss/security/snapshot available in thirdparty repository

> Security Jars Into Thirdparty Repository
> ----------------------------------------
>
>                 Key: SECURITY-2
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-2
>             Project: JBoss Security
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> The JBoss Security Jars should be available via the thirdparty repository.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 14:27:27 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 5 Sep 2006 14:27:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-3) svn move of
 security from jbossas/trunk to jbossas/projects
Message-ID: <6196176.1157480847807.JavaMail.jira@cloud.prod.atl2.jboss.com>

svn move of security from jbossas/trunk to jbossas/projects
-----------------------------------------------------------

                 Key: SECURITY-3
                 URL: http://jira.jboss.com/jira/browse/SECURITY-3
             Project: JBoss Security
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Repository
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Perform a svn move of the security module from jbossas/trunk to jbossas/projects

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 14:35:28 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Tue, 5 Sep 2006 14:35:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1020) Replace direct
 uses of Log4J by JBoss logging.
Message-ID: <5738105.1157481328815.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace direct uses of Log4J by JBoss logging.
----------------------------------------------

                 Key: JBPORTAL-1020
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1020
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4 Final, 2.2 Branch
            Reporter: Chris Laprun
            Priority: Minor
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:23:28 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:23:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-536) The
 CallbackServer cannot be
 contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31980016.1157484208520.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic closed JBMESSAGING-536.
---------------------------------------

    Resolution: Done

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:23:28 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:23:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-536) The
 CallbackServer cannot
 be contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21386994.1157484208678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic reopened JBMESSAGING-536:
-----------------------------------------

             

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:25:31 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:25:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-536) The
 CallbackServer cannot be
 contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2891735.1157484331865.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic closed JBMESSAGING-536.
---------------------------------------

    Fix Version/s: 1.2.0.Alpha1
       Resolution: Done

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:45:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10897988.1157485529197.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=comments#action_12342855 ] 
            
Clebert Suconic commented on JBMESSAGING-499:
---------------------------------------------

the solution is really simple.

Just remove targetos=" windows" and ant would assume the current OS as default.

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:45:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 15:45:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28214344.1157485529333.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=comments#action_12342856 ] 
            
Clebert Suconic commented on JBMESSAGING-499:
---------------------------------------------

Tested this on both Windows (cygwin) and Linux BTW

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 15:49:30 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 5 Sep 2006 15:49:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6915110.1157485770473.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=comments#action_12342858 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-499:
---------------------------------------------

Please also try tests/bin/runtest, tests/bin/start-rmi-server and tests/bin/stop-rmi-server to make sure they work correctly from cygwin.

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:09:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 16:09:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-499)
 get-test-execution-classpath assumes windows
In-Reply-To: <8953736.1155028633193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11709750.1157486969252.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-499?page=all ]

Clebert Suconic closed JBMESSAGING-499.
---------------------------------------

    Fix Version/s: 1.2.0.Alpha1
       Resolution: Done

> get-test-execution-classpath assumes windows
> --------------------------------------------
>
>                 Key: JBMESSAGING-499
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-499
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>
> <target name="get-test-execution-classpath" depends="init">
>       <pathconvert refid="test.execution.classpath" targetos="windows"
>                    property="test.execution.classpath.unix"/>
>       <echo message="${test.execution.classpath.unix}" file="${test.execution.classpath.file}"/>
>    </target>
> The above target in tests/build.xml currently assumes running on Windows resulting in being unable to run runtest on Unix/Linux

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:15:30 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 5 Sep 2006 16:15:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1006) Fix drag & drop
 code to work in IE
In-Reply-To: <9281802.1156994623979.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7855729.1157487330851.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1006?page=all ]

Roy Russo resolved JBPORTAL-1006.
---------------------------------

    Resolution: Done

> Fix drag & drop code to work in IE
> ----------------------------------
>
>                 Key: JBPORTAL-1006
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1006
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Internet Explorer
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Drag&drop javascript code currently works fine in Firefox. Check with Tomek.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:15:31 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 5 Sep 2006 16:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-536) The
 CallbackServer cannot
 be contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28658774.1157487331029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-536:
-----------------------------------------

             
Let's discuss the proper way to fix this here: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3969574#3969574

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:15:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 5 Sep 2006 16:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1021) Fix DnD code to
 work in JDK1.4_
Message-ID: <26516943.1157487331171.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix DnD code to work in JDK1.4_
-------------------------------

                 Key: JBPORTAL-1021
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1021
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Tue Sep  5 16:17:28 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 5 Sep 2006 16:17:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-990) AJAX lib to
 allow user positioning of windows
In-Reply-To: <25250425.1156182220833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30375101.1157487448995.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-990?page=all ]

Roy Russo resolved JBPORTAL-990.
--------------------------------

    Resolution: Done

The prototype is working. Additional tasks will follow wrt integration.

> AJAX lib to allow user positioning of windows
> ---------------------------------------------
>
>                 Key: JBPORTAL-990
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-990
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>
> Implement an AJAX lib to allow user positioning of windows.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 18:14:33 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Tue, 5 Sep 2006 18:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <19986179.1157494473619.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342894 ] 
            
Remy Maucherat commented on JBAS-3345:
--------------------------------------

Thanks for the testing.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 18:24:29 2006
From: jira-events at jboss.com (David Green (JIRA))
Date: Tue, 5 Sep 2006 18:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3624) <security-domain>
 setting in
 deployment descriptor populates @SecurityDomain annotation incorrectly on
 EJB3 session beans
Message-ID: <12582259.1157495069506.JavaMail.jira@cloud.prod.atl2.jboss.com>

<security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans
-------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3624
                 URL: http://jira.jboss.com/jira/browse/JBAS-3624
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: David Green
         Assigned To: Bill Burke


Specifying a <security-domain> in the jboss-app.xml incorrectly sets the @SecurityDomain on EJB3 session beans.

In the jboss-app.xml the security domain is specified as follows:

<jboss-app>
	<security-domain>java:/jaas/hch</security-domain>
</jboss-app>

In Ejb3DescriptorHandler the security-domain is copied directly into the SecurityDomainImpl instance as "java:/jaas/hch", however the @SecurityDomain annotation should be populated with the value "hch" (without the leading "java:/jaas/" prefix).  This causes the EJB3 session bean authentication to behave unexpectedly, since the authentication for the bean reverts to the default domain instead of the specified one.

The only way I've found to workaround this issue is to specify the @SecurityDomain individually on every session bean in the project.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 19:12:43 2006
From: jira-events at jboss.com (Christian Pekeler (JIRA))
Date: Tue, 5 Sep 2006 19:12:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
Message-ID: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>

NotificationBusDemo problem with 2.4CR2
---------------------------------------

                 Key: JGRP-299
                 URL: http://jira.jboss.com/jira/browse/JGRP-299
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4
         Environment: MacOSX, Java 1.5
            Reporter: Christian Pekeler
         Assigned To: Bela Ban


[/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
Starting NotificationBus with name BusDemo
Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
INFO: JGroups version: 2.4CR2
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
INFO: sockets will use interface 192.168.5.142
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
WARNING: traffic class of 8 could not be set, will be ignored
java.net.SocketException: Invalid argument
        at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
        at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
        at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
        at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
        at org.jgroups.protocols.UDP.start(UDP.java:383)
        at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
        at org.jgroups.stack.DownHandler.run(Protocol.java:118)
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
WARNING: traffic class of 8 could not be set, will be ignored
java.net.SocketException: Invalid argument
        at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
        at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
        at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
        at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
        at org.jgroups.protocols.UDP.start(UDP.java:383)
        at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
        at org.jgroups.stack.DownHandler.run(Protocol.java:118)
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets


-- 
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

        


From jira-events at jboss.com  Tue Sep  5 19:40:53 2006
From: jira-events at jboss.com (Michael Panoff (JIRA))
Date: Tue, 5 Sep 2006 19:40:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-189) XDoclet
 configuration dialog broken
Message-ID: <8333307.1157499653009.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-189?page=comments#action_12342910 ] 
            
Michael Panoff commented on JBIDE-189:
--------------------------------------

This issue is back with 1.6.0 GA.  Running on Mac OS 10.4.7 and Eclipse 3.2.0

> XDoclet configuration dialog broken
> -----------------------------------
>
>                 Key: JBIDE-189
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-189
>             Project: JBoss IDE
>          Issue Type: Bug
>    Affects Versions: 1.5 Milestone 1
>         Environment: Linux amd64, Eclipse 3.1RC1 (Build id: I20050527-1300), JBoss IDE 1.5M1 on BEA JRockit JDK1.5 (amd64)
>            Reporter: Sondre Eikanger Kval?
>         Assigned To: Marshall Culpepper
>            Priority: Blocker
>             Fix For: 1.5 Milestone 2
>
>
> In recent builds of Eclipse SDK, the XDoclet configuration dialog (project -> XDoclet Configuration) is broken.  When I try to open the dialog I get the error message "The currently displayed page contains invalid values".
> The error log (see below) reveals that this is caused by a ClassNotFoundException. The class in question is "org.eclipse.jdt.internal.ui.dialogs.StatusDialog". I've checked Eclipse CVS and found that this class was deleted from the repository (it exists in the 'attic'). The last log message says "switching to  org.eclipse.jface.dialogs.StatusDialog" (URL: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/dialogs/Attic/StatusDialog.java ). Maybe you guys should to :-)
> !ENTRY org.eclipse.osgi 2005-06-07 14:17:07.226
> !MESSAGE An error occured while automatically activating bundle org.jboss.ide.eclipse.deployer.ui (88).
> !STACK 0
> org.osgi.framework.BundleException: Exception in org.jboss.ide.eclipse.deployer.ui.DeployerUIPlugin.start() of bundle org.jboss.ide.eclipse.deployer.ui.
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1013)
> 	at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:969)
> 	at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:321)
> 	at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:266)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:112)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:275)
> 	at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
> 	at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1259)
> 	at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:152)
> 	at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:142)
> 	at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:129)
> 	at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:48)
> 	at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:240)
> 	at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:51)
> 	at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:236)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition$1.run(LightweightDecoratorDefinition.java:111)
> 	at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1038)
> 	at org.eclipse.core.runtime.Platform.run(Platform.java:775)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.internalGetDecorator(LightweightDecoratorDefinition.java:107)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:218)
> 	at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:67)
> 	at org.eclipse.core.internal.runtime.InternalPlatform.run(InternalPlatform.java:1038)
> Caused by: java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/deployer/ui/dialogs/TargetEditDialog : org/eclipse/jdt/internal/ui/dialogs/StatusDialog
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown Source)
> Root exception:
> java.lang.NoClassDefFoundError: org/jboss/ide/eclipse/deployer/ui/dialogs/TargetEditDialog : org/eclipse/jdt/internal/ui/dialogs/StatusDialog
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.defineClass(Ljava.lang.String;[BIILjava.security.ProtectionDomain;)Ljava.lang.Class;(Unknown Source)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.defineClass(DefaultClassLoader.java:331)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.defineClass(EclipseClassLoader.java:223)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClassImpl(DefaultClassLoader.java:314)
> 	at org.eclipse.osgi.framework.adaptor.core.DefaultClassLoader.findClass(DefaultClassLoader.java:206)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.findLocalClass(AbstractClassLoader.java:179)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.basicFindLocalClass(EclipseClassLoader.java:137)
> 	at org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalClass(EclipseClassLoader.java:78)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:337)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:389)
> 	at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
> 	at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:74)
> 	at java.lang.ClassLoader.loadClass(Ljava.lang.String;)Ljava.lang.Class;(Unknown Source)
> 	at java.lang.ClassLoader.loadClassFromNative(JLjava.lang.String;)Ljava.lang.Class;(Unknown 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

       



From jira-events at jboss.com  Tue Sep  5 22:56:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 5 Sep 2006 22:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3593) Add a Marshaller to
 HAPartitionImpl
In-Reply-To: <28592223.1157049918621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2895733.1157511403854.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3593?page=all ]

Brian Stansberry closed JBAS-3593.
----------------------------------

    Resolution: Done

> Add a Marshaller to HAPartitionImpl
> -----------------------------------
>
>                 Key: JBAS-3593
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3593
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> HAPartitionImpl is quasi implementing Marshaller by overriding RpcDispatcher.handle() and doing custom *unmarshalling* with MarshalledValueInputStream.  This breaks with JG 2.4, since the default JG marshalling is different and incompatible with the custom unmarshalling.
> Solution to allow use of 2.4+ in 4.0.5+ is to properly implement Marshaller and do the marshalling as well.  This is done in HEAD; need to port to Branch_4_0.  The 4.0 marshaller must use the binary format of the old JGroups method to ensure backward interoperability.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 22:58:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 5 Sep 2006 22:58:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3592) Add system property
 jgroups.mcast.ip_ttl
In-Reply-To: <13362282.1157048839355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9187774.1157511524062.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3592?page=all ]

Brian Stansberry updated JBAS-3592:
-----------------------------------

    Summary: Add system property jgroups.mcast.ip_ttl  (was: Add system property jboss.mcast.ip.ttl)

> Add system property jgroups.mcast.ip_ttl
> ----------------------------------------
>
>                 Key: JBAS-3592
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3592
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Add a system property to all JGroups multicast configs in the AS to control ip_ttl.  Update testsuite build.xml to set this to 1 so running the testsuite doesn't send traffic off the box.

-- 
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

        


From jira-events at jboss.com  Tue Sep  5 23:56:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 5 Sep 2006 23:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-536) The
 CallbackServer cannot be
 contacted for some particular network interface configurations
In-Reply-To: <4090353.1156867039883.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30876626.1157515003933.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-536?page=all ]

Clebert Suconic closed JBMESSAGING-536.
---------------------------------------

    Resolution: Done

> The CallbackServer cannot be contacted for some particular network interface configurations
> -------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-536
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-536
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>          Time Spent: 1 day, 1 hour
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 00:04:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 00:04:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
Message-ID: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>

A testsuite testing client and server on different IPs
------------------------------------------------------

                 Key: JBMESSAGING-540
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
             Project: JBoss Messaging
          Issue Type: Feature Request
            Reporter: Clebert Suconic
         Assigned To: Ovidiu Feodorov
             Fix For: 1.0.1.CR5


The current testsuite tests both client and server on the same network. 
We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 00:04:44 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 00:04:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
In-Reply-To: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3249311.1157515484118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-540?page=all ]

Clebert Suconic reassigned JBMESSAGING-540:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> A testsuite testing client and server on different IPs
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-540
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> The current testsuite tests both client and server on the same network. 
> We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 04:31:30 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:31:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1797) Need to investigate
 the ejb3 admin/monitoring requirements
Message-ID: <19936643.1157531490241.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1797?page=all ]

Dimitris Andreadis updated JBAS-1797:
-------------------------------------

      Component/s: EJB3
                       (was: EJB2)
    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

> Need to investigate the ejb3 admin/monitoring requirements
> ----------------------------------------------------------
>
>                 Key: JBAS-1797
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1797
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>             Fix For: JBossAS-5.0.0.CR1
>
>
> With the integration of the first j2ee5 technology into a jems product, we need to see what the integration issues are from the perspective of the jboss network admin and monitoring integration.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 04:39:32 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:39:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2330) Create Hibernate
 based timer persistence layer
Message-ID: <14997141.1157531972738.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2330?page=all ]

Dimitris Andreadis updated JBAS-2330:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Create Hibernate based timer persistence layer
> ----------------------------------------------
>
>                 Key: JBAS-2330
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2330
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> In the update of the timer service to support persistence independent of the server lifecycle, we should move to a hibernate based pm as opposed to screwing around with sql.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 04:41:30 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:41:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2407) EJB3 integration
Message-ID: <30143191.1157532090545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2407?page=all ]

Dimitris Andreadis updated JBAS-2407:
-------------------------------------

      Component/s: EJB3
                       (was: EJB2)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> EJB3 integration
> ----------------
>
>                 Key: JBAS-2407
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2407
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Need to review EJB3 integartion such that fixes/features don't get lost across EJB2.1/3.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

        


From jira-events at jboss.com  Wed Sep  6 04:41:30 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 04:41:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2848) Tool to analyze
 class loader consistency
Message-ID: <21802430.1157532090741.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2848?page=all ]

Dimitris Andreadis updated JBAS-2848:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Tool to analyze class loader consistency
> ----------------------------------------
>
>                 Key: JBAS-2848
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2848
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Since users don't generally care to think about the typesystem ramifications of the generally conflciting class loader setup allowed in ear deployments as evidenced in the associated forum thread, we need better out of the box smarter than the average deployment archive mess that creates an approriate canonical set of classpaths and class loader configuration. A first step is just a tool that identifies potential problems.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:11:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:11:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1288) Java5 Enum for mbean
 and configurations
Message-ID: <1388432.1157533891442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1288?page=all ]

Dimitris Andreadis updated JBAS-1288:
-------------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

> Java5 Enum for mbean and configurations
> ---------------------------------------
>
>                 Key: JBAS-1288
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1288
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.CR1
>
>
> Whenever you try to get a PropertyEditor for something but none is there, do the following additional check:
> if (type.getSuperclass().getName().equals("java.lang.Enum"))
> {
>    editor = new EnumPropertyEditor(type);
> }
> where the EnumPropertyEditor is:
> public class EnumPropertyEditor extends PropertyEditorSupport implements PropertyEditor
> {
>     private final Class targetType;
>     public EnumPropertyEditor(Class targetType)
>     {
>         this.targetType = targetType;
>     }
>     public void setAsText(String text) throws IllegalArgumentException
>     {
>         try
>         {
>             setValue(targetType.getMethod("valueOf",new Class[]{String.class}).invoke(null,new Object[]{text});
>         } catch (IllegalAccessException e)
>         {
>             throw new IllegalStateException(e);
>         } catch (InvocationTargetException e)
>         {
>             if (e.getTargetException() instanceof RuntimeException);
>                 throw (RuntimeException)e.getTargetException();
>             throw new IllegalStateException(e);
>         } catch (NoSuchMethodException e)
>         {
>             String err = type.getName() +
>                 " does not contain the required method: public static " +
>                  type.getName() + " valueOf(String);";
>             throw new IllegalArgumentException(err,e);
>         }
>         
>     }
>     public String getAsText()
>     {
>     	
>         try
>         {
>             return targetType.getMethod("name",null).invoke(getValue(),null)
>         } catch (IllegalAccessException e)
>         {
>             throw new IllegalStateException(e);
>         } catch (InvocationTargetException e)
>         {
>             if (e.getTargetException() instanceof RuntimeException);
>                 throw (RuntimeException)e.getTargetException();
>             throw new IllegalStateException(e);
>         } catch (NoSuchMethodException e)
>         {
>             String err = type.getName() +
>                 " does not contain the required method: public String name()";
>             throw new IllegalStateException(err,e);
>         }
>     }
> }

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:13:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-460) Make *-service.xml
	'validable'
Message-ID: <11238716.1157534011999.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-460?page=all ]

Dimitris Andreadis updated JBAS-460:
------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Make *-service.xml 'validable'
> ------------------------------
>
>                 Key: JBAS-460
>                 URL: http://jira.jboss.com/jira/browse/JBAS-460
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: MicroContainer bus
>    Affects Versions: JBossAS-4.0.0 Final
>            Reporter: SourceForge User
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: hanming .
> A little while back, I reported this bug:
> https://sourceforge.net/tracker/?func=detail&atid=376685&aid=715680&group_id=22866
> It brought jboss-service_3_2.dtd closer to what David
> Jencks has in mind:
> "we do not have a dtd for *-service files because
> attributes can have xml
>  element values.  AFAIK the only way to cater to this
> is with namespaces and
>  xml schema.  We may need to do this for jboss 4.
>  basically...
>  <depends optional-attribute-name="foo">[object name or
> another mbean
>  dd]</depends>
>  and
>  <depends-list optional-attribute-name="bar">
>    <depends-list-element>[o-n or mbean
> dd]</depends-list-element>
>    <depends-list-element>[o-n or mbean
> dd]</depends-list-element>
>  ...
>  </depends-list>"
> jboss-service_3_2.dtd is as good a DTD as in reflecting
> what David has in mind but it has a major problem: it
> can never be used to validate any *-service.xml file.
> This is because XML 1.0 can never have this kind of
> construct (represented here as using DTD language, as
> opposed to Schema because it cannot be represented
> using the latter):
> <!ELEMENT depends (#PCDATA | mbean)>
> The closest that one can come up with is
> <!ELEMENT depends (#PCDATA | mbean)*>
> This is how XML 1.0 (may XML 1.1 changes it, I don't
> know) deal with a class of SGML problem known as the
> 'pernicious mixed content". Search Google for more details.
> http://www.w3.org/TR/REC-xml#sec-mixed-content
> Summary:
> ---------------
> I know it's too late to change anything for 3.2 but I
> have suggestions for 4.0
> 1. Don't use mixed content, if possible. It's easy to
> get it wrong in different level: API, parsing and
> writing of DTDs/Schemas.
> 2. The easiest local workaround for the element
> <depends> is to use Element wrapper pattern, e.g:
> <!ELEMENT depends-content (#PCDATA)>
> <!ELEMENT depends (depends-content | mbean)>
> But that might not be a good overall solution.
> 3. Bear in mind that XML Schema in designed to work
> with XML 1.0, hence the closest one can use Schema to
> constraint <depends> is:
>   <xs:element name="depends">
>     <xs:complexType mixed="true">
>       <xs:choice>
>         <xs:element ref="mbean"/>
>       </xs:choice>
>       <xs:attribute name="optional-attribute-name"
> type="xs:string"/>
>     </xs:complexType>
>   </xs:element>
> which is not really what David's original intention is.
> Thank you, Han Ming

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:17:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:17:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2148) ServerInfo MBean
 operations return HTML code as java.lang.String
Message-ID: <14903458.1157534257847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2148?page=all ]

Dimitris Andreadis closed JBAS-2148.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Rejected

Won't deal with this, unless someone wants to contribute.

> ServerInfo MBean operations return HTML code as java.lang.String
> ----------------------------------------------------------------
>
>                 Key: JBAS-2148
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2148
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: Fedora Core 4 (x86-32bit)
> JDK5.0_04
> unmodified minimal server configuration
> System.properties from: http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMBeansInJConsole
>            Reporter: Mikko Tiihonen
>            Priority: Minor
>
> The ServerInfo MBean which can be viewed through the Java 5.0 jconsole returns responses to operations as Strings that contain HTML code.
> Instead of <TABLE><TR><TD>... etc the operations should return objects that implement MBean interface or they should be split to smaller operations that can show simple objects.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 05:21:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 05:21:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3167) Support Pack200
 compression for WAR/EAR files to reduce upload time
Message-ID: <5847090.1157534493829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3167?page=all ]

Dimitris Andreadis updated JBAS-3167:
-------------------------------------

        Fix Version/s:     (was: JBossAS-4.0.5.GA)
    Affects Version/s: JBossAS-4.0.2 Final
                           (was: JBossAS-4.0.4.CR2)

If someone wants to prototype this fine, but for now there are no cycles for it.

> Support Pack200 compression for WAR/EAR files to reduce upload time
> -------------------------------------------------------------------
>
>                 Key: JBAS-3167
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3167
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: n/a
>            Reporter: Richard Kennard
>            Priority: Optional
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> First, thank you for such an outstanding Application Server: JBoss is truly a magnificent piece of software that is an absolute joy to work with. You guys are a shining testament to the quality of Open Source.
> My feature request is to support Sun's new(ish) Pack200 compression format for WARs and EARs. I know precious little about this, other than it is built into the JRE and can pack JARs to a fraction of their original size. I'm not even sure it can be applied 'as is' to WARs and EARs, so perhaps this can be a proprietary JBoss feature?
> Anyway, at 20MB+ an EAR takes a good 10-15 minutes to upload to my hosting service using my home broadband connection, so any move to help reduce EAR size would be a boon.
> I understand that Pack200 JARs must first be uncompressed into JARs before they can be used, but this should be fairly natural for JBoss (which uncompresses into the tmp folder anyway, I believe).

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 06:13:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 06:13:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3625) Update
Message-ID: <13328214.1157537614191.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update 
-------

                 Key: JBAS-3625
                 URL: http://jira.jboss.com/jira/browse/JBAS-3625
             Project: JBoss Application Server
          Issue Type: 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

        


From jira-events at jboss.com  Wed Sep  6 06:17:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 06:17:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3625) Update EJB3 for
	jboss-4.0.5.GA
In-Reply-To: <13328214.1157537614191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8755598.1157537853399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3625?page=all ]

Dimitris Andreadis updated JBAS-3625:
-------------------------------------

              Summary: Update EJB3 for jboss-4.0.5.GA  (was: Update )
          Component/s: EJB3
        Fix Version/s: JBossAS-4.0.5.GA
    Affects Version/s: JBossAS-4.0.5.CR1
          Description: Merge EJB3 changes to Branch_4_0, take care of any library dependency issues (e.g. new remoting version required?)
             Assignee: Bill Burke

> Update EJB3 for jboss-4.0.5.GA
> ------------------------------
>
>                 Key: JBAS-3625
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3625
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> Merge EJB3 changes to Branch_4_0, take care of any library dependency issues (e.g. new remoting version required?)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 06:29:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 06:29:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3626) Upgrade jbossws to
	1.0.4.GA
Message-ID: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jbossws to 1.0.4.GA
---------------------------

                 Key: JBAS-3626
                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Dimitris Andreadis
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.5.GA


Upgrade to jbossws-1.0.4.GA, when it becomes available

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 06:47:29 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Wed, 6 Sep 2006 06:47:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3627) Write test to test
 rollback of a NACK in 2PC
Message-ID: <22340756.1157539649297.JavaMail.jira@cloud.prod.atl2.jboss.com>

Write test to test rollback of a NACK in 2PC
--------------------------------------------

                 Key: JBAS-3627
                 URL: http://jira.jboss.com/jira/browse/JBAS-3627
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JMS service
            Reporter: Luc Texier
         Assigned To: Adrian Brock
             Fix For: JBossAS-4.0.5.GA


Need to test BasicQueue.acknowledge()
whether it should also add a PostRollback task for a NACK under a transaction.

i.e. 

      // Was it a negative acknowledge??
      if (!item.isAck)
      {
         Runnable task = new RestoreMessageTask(m);
         server.getPersistenceManager().getTxManager().addPostCommitTask(txId, task);
+         server.getPersistenceManager().getTxManager().addPostRollbackjTask(txId, task);
      }

The  hard part is wrting such a test since it is a normal condition.
Probably need to use direct invocation on the server invoker ?

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 07:01:29 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Wed, 6 Sep 2006 07:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3628) Invalid fix for
	JBAS-3573
Message-ID: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invalid fix for JBAS-3573
-------------------------

                 Key: JBAS-3628
                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Luc Texier
         Assigned To: Luc Texier
             Fix For: JBossAS-4.0.5.GA



in case of an exception, both  a PostCommit Task and a PostRollback Task should be added

         try
         {
            if (m.isPersistent())
               server.getPersistenceManager().remove(m, txId);
         }
         catch (Throwable t)
         {
            // Something is wrong with the persistence manager,
            // force a NACK with a rollback/error
            Runnable task = new RestoreMessageTask(m);
            TxManager txManager = server.getPersistenceManager().getTxManager();
+          txManager.addPostCommitTask(txId, task);            
            txManager.addPostRollbackTask(txId, task);
            SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Wed Sep  6 07:46:28 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 07:46:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3586) Upgrade Tomcat to
	Version 5.5.18
In-Reply-To: <15166838.1156950344122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7159289.1157543188301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3586?page=all ]

Dimitris Andreadis closed JBAS-3586.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis  (was: Anil Saldhana)

Updated Branch_4_0.

> Upgrade Tomcat to Version 5.5.18
> --------------------------------
>
>                 Key: JBAS-3586
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3586
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> We have to ensure that Tomcat needs to be upgraded to the latest version available at the release of 4.0.5.GA
> Just before the release happens and this issue is being closed, we need to update the *title* of this JIRA issue to indicate the correct version of Tomcat that is included.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:10:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:10:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2133) use left join in
 jboss-3.2.7 with oracle8.1.7.0.1
Message-ID: <22776571.1157544633352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2133?page=all ]

Dimitris Andreadis updated JBAS-2133:
-------------------------------------

       Issue Type: Feature Request  (was: Bug)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> use left join in jboss-3.2.7 with oracle8.1.7.0.1
> -------------------------------------------------
>
>                 Key: JBAS-2133
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2133
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: fedora core 3 ,jrockit 1.4.2_05
>            Reporter: peixubin
>             Fix For: JBossAS-4.0.6.CR1
>
>
> I have this jbossquery:
> <query-method>
> <method-name>findByCounte</method-name>
> <method-params>
> <method-param>java.lang.String</method-param>
> </method-params>
> </query-method>
> <jboss-ql><![CDATA[SELECT OBJECT(o) FROM JhFyck o WHERE o.counte.name=?1]]></jboss-ql>
> <read-ahead>
> on-find
> <eager-load-group>*</eager-load-group>
> <left-join cmr-field="jhFyk" eager-load-group="*"/>
> </read-ahead>
> while I execute this find method,the console print errors:
> 10:35:44,374 DEBUG [JhFyck#findByCounte] Executing SQL: SELECT t0_o.PKID, t0_o.FYLX, t0_o.RKSJ, t0_o.RKR, t0_o.CWM, t0_o.FYH, t0_o.FYK, t0_o.RKPC, t0_o.RCPC, t0_o.ZT, t0_o.BFR, t0_o.BFSJ, t1 _o_jhFyk.PKID, t1_o_jhFyk.P_PKID, t1_o_jhFyk.MC, t1_o_jhFyk.BM, t1_o_jhFyk.X, t1_o_jhFyk.Y, t1_ o_jhFyk.ZT FROM PXB.JH_FYCK t0_o, YD.COUNTE t2_o_counte, JH_COUNTE_FY t3_o_counte_RELATION_TABLE LEFT OUTER JOIN PXB.JH_FYK t1_o_jhFyk ON t0_o.FYK=t1_o_jhFyk.PKID WHERE (t2_o_counte.NAME = ? AND t0_o.PKID=t3_o_counte_RELATION_TABLE.FYBH AND t2_o_counte.NAME=t3_o_counte_RELATION_TABLE. COUNTE)
> 10:35:44,405 ERROR [JhFyck#findByCounte] Find failed
> java.sql.SQLException: ORA-00933: SQL command not properly ended
> at oracle.jdbc.dbaccess.DBError.throwSqlException(Ljava.lang.String;Ljava.lang.String;I )V(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError()V(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive()V(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(BBI[B[Loracle.jdbc.dbaccess.DBType;[Loracle.jd bc.dbaccess.DBData;I[Loracle.jdbc.dbaccess.DBType;[Loracle.jdbc.dbaccess.DBData;I)V(TTC7Protoco l.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(Loracle.jdbc.dbaccess.DBStatement ;[BLoracle.jdbc.dbaccess.DBDataSet;)[Loracle.jdbc.dbaccess.DBColumn;(TTC7Protocol.java:643)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery()V(OracleStatement.java:1674)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout()V(OracleStatement.java:1870 )
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate()I(OraclePreparedStatement. java:363)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery()Ljava.sql.ResultSet;(Oracle PreparedStatement.java:314)
> at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeQuery()Ljava.sql.Res ultSet;(WrappedPreparedStatement.java:314)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(Ljava.lang.String;[L java.lang.Object;IILorg.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCEntityBridge;Lorg.jboss.ejb.plugi ns.cmp.jdbc.bridge.JDBCCMPFieldBridge;Lorg.jboss.ejb.plugins.cmp.ejbql.SelectFunction;Lorg.jbos s.ejb.plugins.cmp.jdbc.JDBCStoreManager;[ZLjava.util.List;Ljava.util.List;Lorg.jboss.ejb.plugin s.cmp.jdbc.metadata.JDBCQueryMetaData;Lorg.jboss.ejb.GenericEntityObjectFactory;Lorg.jboss.logg ing.Logger;)Ljava.util.Collection;(JDBCAbstractQueryCommand.java:226)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(Ljava.lang.reflect.M ethod;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObj ectFactory;)Ljava.util.Collection;(JDBCAbstractQueryCommand.java:128)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(Ljava.lang.reflect.Me thod;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObje ctFactory;)Ljava.util.Collection;(JDBCFindEntitiesCommand.java:40)
> at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(Ljava.lang.reflect.Meth od;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObject Factory;)Ljava.util.Collection;(JDBCStoreManager.java:598)
> at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(Ljava.lang.reflect.Method;[ Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.GenericEntityObjectFact ory;)Ljava.util.Collection;(CMPPersistenceManager.java:278)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntities(Ljava. lang.reflect.Method;[Ljava.lang.Object;Lorg.jboss.ejb.EntityEnterpriseContext;Lorg.jboss.ejb.Ge nericEntityObjectFactory;)Ljava.util.Collection;(CachedConnectionInterceptor.java:325)
> at org.jboss.ejb.EntityContainer.findLocal(Lorg.jboss.invocation.Invocation;)Ljava.lang .Object;(EntityContainer.java:609)
> at jrockit.reflect.NativeMethodInvoker.invoke0(Ljava.lang.Object;ILjava.lang.Object;[Lj ava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> at jrockit.reflect.NativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Lja va.lang.Object;(Unknown Source)
> at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Obje ct;)Ljava.lang.Object;(Unknown Source)
> at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Ob ject;(Unknown Source)
> at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(Lorg.jboss.invocation. Invocation;)Ljava.lang.Object;(EntityContainer.java:1066)
> at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(Lorg.jboss.invocation.Invocatio n;)Ljava.lang.Object;(AbstractInterceptor.java:88)
> at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(Lorg.jboss.invocat ion.Invocation;)Ljava.lang.Object;(EntitySynchronizationInterceptor.java:204)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(Lorg.jbo ss.invocation.Invocation;)Ljava.lang.Object;(CachedConnectionInterceptor.java:215)
> at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(Lorg.jboss.invocation.Invocatio n;)Ljava.lang.Object;(AbstractInterceptor.java:88)
> at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(Lorg.jboss.invocation.Inv ocation;)Ljava.lang.Object;(EntityInstanceInterceptor.java:97)
> at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(Lorg.jboss.invocation.Invocat ion;)Ljava.lang.Object;(EntityLockInterceptor.java:61)
> at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(Lorg.jboss.invocation.Inv ocation;)Ljava.lang.Object;(EntityCreationInterceptor.java:28)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(Lorg.jboss.invocation.Invocat ion;Z)Ljava.lang.Object;(AbstractTxInterceptor.java:88)
> at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(Lorg.jboss.invocation.Inv ocation;)Ljava.lang.Object;(TxInterceptorCMT.java:317)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(Lorg.jboss.invocation.Invocation;) Ljava.lang.Object;(TxInterceptorCMT.java:130)
> Oracle not support left join syntax,how to configure jboss to use oracle-style left-join?

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:20:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2222) Add support to
 LdapExtLoginModule for user searches that return a referral
Message-ID: <20945409.1157545229186.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2222?page=all ]

Dimitris Andreadis updated JBAS-2222:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Move feature requests to the next release

> Add support to LdapExtLoginModule for user searches that return a referral
> --------------------------------------------------------------------------
>
>                 Key: JBAS-2222
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2222
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The current LdapExtLoginModule cannot handle a user search that returns a referral. We need to look into supporting following the referral to authenticate the user against the target server.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:20:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:20:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2831) Allow run-as
 indentity propagation across servers with configurable trust
Message-ID: <23700617.1157545229526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2831?page=all ]

Dimitris Andreadis updated JBAS-2831:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Move new feature requests to the next release.

> Allow run-as indentity propagation across servers with configurable trust
> -------------------------------------------------------------------------
>
>                 Key: JBAS-2831
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2831
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4RC1
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Look to provide propagation of the run-as identity across server calls with control over how the target server trusts this call is correct.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 08:24:28 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 6 Sep 2006 08:24:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2243)
 UsernamePassword/DatabaseServerLoginModule reveal to much information
Message-ID: <22574264.1157545468205.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2243?page=all ]

Dimitris Andreadis updated JBAS-2243:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> UsernamePassword/DatabaseServerLoginModule reveal to much information
> ---------------------------------------------------------------------
>
>                 Key: JBAS-2243
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2243
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: 4.0.3RC2/EJB3
>            Reporter: Jens Elkner
>
> If an authentication fails, the thrown javax.security.auth.login.FailedLoginException has a detailed message, which says "Password Incorrect/Password Required" or "No matching username found in Principals". These are pretty good information for an attacker, since than it knows, where to continue its attack and is able to skip a lot of tasks (no matter, whether it comes from the internal or external network - in our days, attacks from internal is probably the most common case). 
> Actually, that's also the reason, why many authentication systems just insert even a delay to not let the attacker guess, whether the guessed username was wrong or the guessed password (minimal, but measurable delay dueto en/decryption) ...
> So, logging those details might be ok, but revealing those infos to the client is without any doubt a security issue!

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:34:36 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-12) Release WS-Context
 implementation and re-factor
Message-ID: <13184349.1157549676054.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-12?page=all ]

Mark Little updated JBESB-12:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Release WS-Context implementation and re-factor
> -----------------------------------------------
>
>                 Key: JBESB-12
>                 URL: http://jira.jboss.com/jira/browse/JBESB-12
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.1
>
>
> The ESB architecture has a notion of a message context. In Web Services, the standard approach for this is OASIS WS-Context. Although our ESB is not tied to Web Services, it makes sense that we should support WS-Context. We already have an implementation that has been tested for interoperability with IONA and Oracle, so this is a good starting point. It will need some updating to bring it in line with the latest version of the specification.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:52:28 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:52:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-86) Identify what QA and
 unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28864816.1157550748768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-86?page=all ]

Mark Little updated JBESB-86:
-----------------------------

    Assignee: Tom Fennelly  (was: Mark Little)

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 09:54:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:54:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-113) Improve
	documentation
In-Reply-To: <5394662.1154687171848.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10415300.1157550870988.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-113?page=comments#action_12342938 ] 
            
Mark Little commented on JBESB-113:
-----------------------------------

This is an ongoing task. Will close as a result.

> Improve documentation
> ---------------------
>
>                 Key: JBESB-113
>                 URL: http://jira.jboss.com/jira/browse/JBESB-113
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> The programmers guide for the beta needs improving, with much more explicit information on classes, what they are for, how they are used and configuration information. What we have for the beta release will require augmentation via the forums and that is not an ideal situation.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:54:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:54:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-113) Improve documentation
In-Reply-To: <5394662.1154687171848.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24836539.1157550871091.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-113?page=all ]

Mark Little closed JBESB-113.
-----------------------------

    Resolution: Done

> Improve documentation
> ---------------------
>
>                 Key: JBESB-113
>                 URL: http://jira.jboss.com/jira/browse/JBESB-113
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> The programmers guide for the beta needs improving, with much more explicit information on classes, what they are for, how they are used and configuration information. What we have for the beta release will require augmentation via the forums and that is not an ideal situation.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:56:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-120) ObjectStore
 configured differently from other components
In-Reply-To: <8533363.1154951052094.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5788660.1157550991229.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-120?page=all ]

Mark Little updated JBESB-120:
------------------------------

    Assignee: Kurt Stam  (was: Mark Little)

> ObjectStore configured differently from other components
> --------------------------------------------------------
>
>                 Key: JBESB-120
>                 URL: http://jira.jboss.com/jira/browse/JBESB-120
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.0
>
>
> Why does the object store configuration work differently from other components? Specifically, it doesn't use the ParamsRepository approach.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:56:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-123) Remove hardcoded
	class names
In-Reply-To: <1140887.1155045312458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24231562.1157550991415.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-123?page=all ]

Mark Little updated JBESB-123:
------------------------------

    Assignee: Daniel Brum  (was: Mark Little)

> Remove hardcoded class names
> ----------------------------
>
>                 Key: JBESB-123
>                 URL: http://jira.jboss.com/jira/browse/JBESB-123
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0
>
>
>       Class oCls = Class.forName("org.jboss.soa.esb.util.BobjStdDTO");

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:56:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-15) Basic transformation
 integration using Smooks
Message-ID: <16675567.1157550992311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-15?page=all ]

Mark Little updated JBESB-15:
-----------------------------

    Component/s: Transformation Service
                     (was: ESB Core)

> 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
>             Fix For: 4.0
>
>
> 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

        


From jira-events at jboss.com  Wed Sep  6 09:56:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:56:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-22) Transformation
	service interface
Message-ID: <13160685.1157550992706.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-22?page=all ]

Mark Little updated JBESB-22:
-----------------------------

    Component/s: Transformation Service

> Transformation service interface
> --------------------------------
>
>                 Key: JBESB-22
>                 URL: http://jira.jboss.com/jira/browse/JBESB-22
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transformation Service
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>             Fix For: 4.0
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> We need to agree on the interface (in the forum) and then provide it/them.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 09:58:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-62) Change jar names
Message-ID: <1940883.1157551111769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-62?page=all ]

Mark Little updated JBESB-62:
-----------------------------

    Component/s: Distribution

> Change jar names
> ----------------
>
>                 Key: JBESB-62
>                 URL: http://jira.jboss.com/jira/browse/JBESB-62
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 09:58:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-134) Content-based
	routing support
In-Reply-To: <14800145.1155656179686.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18514089.1157551111927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-134?page=all ]

Mark Little updated JBESB-134:
------------------------------

    Component/s: Content Based Routing
                     (was: ESB Core)

> Content-based routing support
> -----------------------------
>
>                 Key: JBESB-134
>                 URL: http://jira.jboss.com/jira/browse/JBESB-134
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Content Based Routing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 09:58:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 09:58:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-21) Registry service
	interface
Message-ID: <7967047.1157551111652.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-21?page=all ]

Mark Little updated JBESB-21:
-----------------------------

    Component/s: Registry
                     (was: ESB Core)

> Registry service interface
> --------------------------
>
>                 Key: JBESB-21
>                 URL: http://jira.jboss.com/jira/browse/JBESB-21
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Registry
>            Reporter: Mark Little
>         Assigned To: Mugdho
>             Fix For: 4.0
>
>
> We need a registry. It cannot be WS specific, but JAX-R looks like it still matches. Check out what is available in JBossWS (or elsewhere). Assuming we go the JAX-R route (discuss on forum please), then we need stand-alone JAX-R support and a plugin.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:04:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:04:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6038807.1157551472423.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little updated JBESB-104:
------------------------------

    Assignee: Daniel Brum  (was: Mark Little)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:04:32 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 6 Sep 2006 10:04:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-649)
 IdentityLock.getFqn() always returns Fqn.ROOT
Message-ID: <19030567.1157551472560.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-649?page=comments#action_12342941 ] 
            
Brian Stansberry commented on JBCACHE-649:
------------------------------------------

Please note that this issue was to fix an issue that cropped up during 1.4 development.  The problem was never in any released version of JBoss Cache, not even a beta.

> IdentityLock.getFqn() always returns Fqn.ROOT
> ---------------------------------------------
>
>                 Key: JBCACHE-649
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-649
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 1.4.0
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Somewhere along the way the fqn field got removed from IdentityLock, and getFqn() got hardcoded to always return Fqn.ROOT.  This leads to misleading exception messages and log statements like "org.jboss.cache.lock.TimeoutException: read lock for / could not be acquired by ..."  -- when actually the problem was on "/JSESSON/localhost".  Just spent an hour on a fruitless search for who could have a WL on "/" .

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:04:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:04:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-60) Place non-public
 classes and interfaces into internal package structure
Message-ID: <29447246.1157551472759.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-60?page=all ]

Mark Little updated JBESB-60:
-----------------------------

    Assignee: Esteban Schifman  (was: Mark Little)

> Place non-public classes and interfaces into internal package structure
> -----------------------------------------------------------------------
>
>                 Key: JBESB-60
>                 URL: http://jira.jboss.com/jira/browse/JBESB-60
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:06:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-58) Add back EPR
	functionality
Message-ID: <27983204.1157551593029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-58?page=all ]

Mark Little updated JBESB-58:
-----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]
    Priority: Critical  (was: Major)

> Add back EPR functionality
> --------------------------
>
>                 Key: JBESB-58
>                 URL: http://jira.jboss.com/jira/browse/JBESB-58
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> Prior to Rosetta, the Alpha 1 codebase has the EPR capabilities. Add this back.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:06:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-59) Add in generic bus
	abstraction
Message-ID: <26143891.1157551593161.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-59?page=all ]

Mark Little updated JBESB-59:
-----------------------------

    Priority: Critical  (was: Major)

> Add in generic bus abstraction
> ------------------------------
>
>                 Key: JBESB-59
>                 URL: http://jira.jboss.com/jira/browse/JBESB-59
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> Prior to Rosetta, we had the notion of a generic bus with client/service plugins, dispatchers and a message format. All of this needs to be added back to the new codebase.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:06:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-48) I18N/L10N compliance
Message-ID: <29853481.1157551593377.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-48?page=all ]

Mark Little updated JBESB-48:
-----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.)]
    Priority: Optional  (was: Major)

> I18N/L10N compliance
> --------------------
>
>                 Key: JBESB-48
>                 URL: http://jira.jboss.com/jira/browse/JBESB-48
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Optional
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:08:31 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 6 Sep 2006 10:08:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-649)
 IdentityLock.getFqn() always returns Fqn.ROOT
Message-ID: <2226008.1157551711994.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-649?page=comments#action_12342942 ] 
            
Brian Stansberry commented on JBCACHE-649:
------------------------------------------

Previous comment incorrect; it was broken in 1.4.0.Alpha and 1.4.0.Beta, fixed in 1.4.0.Beta2.

> IdentityLock.getFqn() always returns Fqn.ROOT
> ---------------------------------------------
>
>                 Key: JBCACHE-649
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-649
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 1.4.0
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Somewhere along the way the fqn field got removed from IdentityLock, and getFqn() got hardcoded to always return Fqn.ROOT.  This leads to misleading exception messages and log statements like "org.jboss.cache.lock.TimeoutException: read lock for / could not be acquired by ..."  -- when actually the problem was on "/JSESSON/localhost".  Just spent an hour on a fruitless search for who could have a WL on "/" .

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:08:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:08:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-39) Add more QA and unit
	tests
Message-ID: <17171849.1157551712181.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-39?page=all ]

Mark Little updated JBESB-39:
-----------------------------

    Priority: Critical  (was: Major)

> Add more QA and unit tests
> --------------------------
>
>                 Key: JBESB-39
>                 URL: http://jira.jboss.com/jira/browse/JBESB-39
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 week, 4 minutes
>  Remaining Estimate: 0 minutes
>
> The Rosetta codebase does not come with a lot of tests. We need a lot more before the beta release and certainly for the 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

        


From jira-events at jboss.com  Wed Sep  6 10:08:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:08:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-119) Parameter loading
 doesn't check for XML validity
In-Reply-To: <7780536.1154950212823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7450909.1157551712324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-119?page=all ]

Mark Little updated JBESB-119:
------------------------------

    Priority: Critical  (was: Major)

> Parameter loading doesn't check for XML validity
> ------------------------------------------------
>
>                 Key: JBESB-119
>                 URL: http://jira.jboss.com/jira/browse/JBESB-119
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> The current ParamRepository approach has a File implementation. It all appears to work on Strings (with the comments indicating how the strings should be formatted for structured attributes). However, some user classes assume the String is XML. Parameters should be provided to application classes through name/value pairs. How those pairs are loaded into the system (XML, strings, file, etc.) should be hidden.
> We also need an ESB schema.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:08:32 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 6 Sep 2006 10:08:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-15) Basic
 transformation integration using Smooks
Message-ID: <26368879.1157551712485.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-15?page=comments#action_12342943 ] 
            
Tom Fennelly commented on JBESB-15:
-----------------------------------

Will start by integrating it into the existing Rosetta architecture.  This will change considerably once the "ultimate" architecture is evolved.

> 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
>             Fix For: 4.0
>
>
> 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

        


From jira-events at jboss.com  Wed Sep  6 10:10:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-122) Schema needed
In-Reply-To: <17213696.1154955972421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2655231.1157551831290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-122?page=all ]

Mark Little updated JBESB-122:
------------------------------

    Priority: Critical  (was: Major)

> Schema needed
> -------------
>
>                 Key: JBESB-122
>                 URL: http://jira.jboss.com/jira/browse/JBESB-122
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>
> XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:10:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-22) Transformation
	service interface
Message-ID: <24782726.1157551831488.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-22?page=all ]

Mark Little updated JBESB-22:
-----------------------------

    Priority: Critical  (was: Major)

> Transformation service interface
> --------------------------------
>
>                 Key: JBESB-22
>                 URL: http://jira.jboss.com/jira/browse/JBESB-22
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transformation Service
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> We need to agree on the interface (in the forum) and then provide it/them.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:10:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1021) Fix DnD code to
 work in JDK1.4_
In-Reply-To: <26516943.1157487331171.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18379052.1157551831614.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1021?page=all ]

Roy Russo resolved JBPORTAL-1021.
---------------------------------

    Resolution: Done

> Fix DnD code to work in JDK1.4_
> -------------------------------
>
>                 Key: JBPORTAL-1021
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1021
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-21) Registry service
	interface
Message-ID: <26920387.1157551950222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-21?page=all ]

Mark Little updated JBESB-21:
-----------------------------

    Priority: Critical  (was: Major)

> Registry service interface
> --------------------------
>
>                 Key: JBESB-21
>                 URL: http://jira.jboss.com/jira/browse/JBESB-21
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Registry
>            Reporter: Mark Little
>         Assigned To: Mugdho
>            Priority: Critical
>             Fix For: 4.0
>
>
> We need a registry. It cannot be WS specific, but JAX-R looks like it still matches. Check out what is available in JBossWS (or elsewhere). Assuming we go the JAX-R route (discuss on forum please), then we need stand-alone JAX-R support and a plugin.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-134) Content-based
	routing support
In-Reply-To: <14800145.1155656179686.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7188541.1157551950528.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-134?page=all ]

Mark Little updated JBESB-134:
------------------------------

    Priority: Critical  (was: Major)

> Content-based routing support
> -----------------------------
>
>                 Key: JBESB-134
>                 URL: http://jira.jboss.com/jira/browse/JBESB-134
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Content Based Routing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Critical
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30963434.1157551950783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little updated JBESB-104:
------------------------------

    Priority: Critical  (was: Major)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>            Priority: Critical
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:12:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-15) Basic transformation
 integration using Smooks
Message-ID: <15617767.1157551950959.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-15?page=all ]

Mark Little updated JBESB-15:
-----------------------------

    Priority: Critical  (was: Major)

> 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
>
>
> 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

        


From jira-events at jboss.com  Wed Sep  6 10:12:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-55) Nightly builds of
	unit tests
Message-ID: <7166526.1157551951126.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-55?page=all ]

Mark Little updated JBESB-55:
-----------------------------

    Priority: Critical  (was: Minor)

> Nightly builds of unit tests
> ----------------------------
>
>                 Key: JBESB-55
>                 URL: http://jira.jboss.com/jira/browse/JBESB-55
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Critical
>             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:14:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 10:14:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-135) Integration with
 Microcontainer (IoC abstraction)
Message-ID: <11365425.1157552071692.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integration with Microcontainer (IoC abstraction)
-------------------------------------------------

                 Key: JBESB-135
                 URL: http://jira.jboss.com/jira/browse/JBESB-135
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Kevin Conner
            Priority: Critical
             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep  6 10:26:31 2006
From: jira-events at jboss.com (Matias Zaya Mendez (JIRA))
Date: Wed, 6 Sep 2006 10:26:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-475) Error in
 documentation concerning the joining of constarints
Message-ID: <21882515.1157552791961.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error in documentation concerning the joining of constarints
------------------------------------------------------------

                 Key: JBRULES-475
                 URL: http://jira.jboss.com/jira/browse/JBRULES-475
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 3.0.4
            Reporter: Matias Zaya Mendez
         Assigned To: Mark Proctor
            Priority: Trivial


In the documentation it is specified that in the DSL in order to create join constraints you define them as such:
(URL:http://labs.jboss.com/file-access/default/members/jbossrules/freezone/docs/3.0.4/html_single/index.html)

[when]There is a Cheese with=Cheese()
[when]-age is less than {age}=age<{age}
[when]-type is '{type}'=type=='{type}'
[when]-country equal to '{country}'=country=='{country}'

Actually, there must be a space between the "dash" and the constraint, such as:

[when]There is a Cheese with=Cheese()
[when]- age is less than {age}=age<{age}
[when]- type is '{type}'=type=='{type}'
[when]- country equal to '{country}'=country=='{country}'

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:30:34 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1007) Fix drag & drop
 code to work in Konqueror
In-Reply-To: <2383186.1156994624285.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24345669.1157553034767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1007?page=all ]

Roy Russo resolved JBPORTAL-1007.
---------------------------------

    Resolution: Done

> Fix drag & drop code to work in Konqueror
> -----------------------------------------
>
>                 Key: JBPORTAL-1007
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1007
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>         Environment: Konqueror
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> check with Tomek.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:30:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 10:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <10618400.1157553035307.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic reassigned JBAS-2299:
-------------------------------------

    Assignee: Clebert Suconic

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:30:36 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:30:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1010) Window drag&drop
In-Reply-To: <24406364.1156995464631.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18520688.1157553036351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1010?page=all ]

Roy Russo reassigned JBPORTAL-1010:
-----------------------------------

    Assignee: Roy Russo

> Window drag&drop
> ----------------
>
>                 Key: JBPORTAL-1010
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1010
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> placeholder super-task for all drag&drop tasks

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:32:30 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 6 Sep 2006 10:32:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-22) Transformation
	service interface
Message-ID: <8112623.1157553150768.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-22?page=comments#action_12342946 ] 
            
Tom Fennelly commented on JBESB-22:
-----------------------------------

Where are we with this at the minute:
1. Forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81237,  http://www.jboss.org/index.html?module=bb&op=viewtopic&t=82506
2. Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=TransformationServices

> Transformation service interface
> --------------------------------
>
>                 Key: JBESB-22
>                 URL: http://jira.jboss.com/jira/browse/JBESB-22
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Transformation Service
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> We need to agree on the interface (in the forum) and then provide it/them.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:32:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:32:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1022) Remove
 unecessary ui libs from DnD code
Message-ID: <24899762.1157553151522.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove unecessary ui libs from DnD code
---------------------------------------

                 Key: JBPORTAL-1022
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1022
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 10:54:35 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 6 Sep 2006 10:54:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1022) Remove
 unecessary ui libs from DnD code
In-Reply-To: <24899762.1157553151522.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <616831.1157554475374.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1022?page=all ]

Roy Russo resolved JBPORTAL-1022.
---------------------------------

    Resolution: Done

> Remove unecessary ui libs from DnD code
> ---------------------------------------
>
>                 Key: JBPORTAL-1022
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1022
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:07:29 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Wed, 6 Sep 2006 11:07:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14248950.1157555250003.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Luc Texier updated JBAS-3628:
-----------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
      Description: 
in case of an exception, both  a PostCommit Task and a PostRollback Task should be added

         try
         {
            if (m.isPersistent())
               server.getPersistenceManager().remove(m, txId);
         }
         catch (Throwable t)
         {
            // Something is wrong with the persistence manager,
            // force a NACK with a rollback/error
            Runnable task = new RestoreMessageTask(m);
            TxManager txManager = server.getPersistenceManager().getTxManager();
+          txManager.addPostCommitTask(txId, task);            
            txManager.addPostRollbackTask(txId, task);
            SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, t);
         }

  was:

in case of an exception, both  a PostCommit Task and a PostRollback Task should be added

         try
         {
            if (m.isPersistent())
               server.getPersistenceManager().remove(m, txId);
         }
         catch (Throwable t)
         {
            // Something is wrong with the persistence manager,
            // force a NACK with a rollback/error
            Runnable task = new RestoreMessageTask(m);
            TxManager txManager = server.getPersistenceManager().getTxManager();
+          txManager.addPostCommitTask(txId, task);            
            txManager.addPostRollbackTask(txId, task);
            SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, t);
         }


> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Luc Texier
>         Assigned To: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Wed Sep  6 11:09:33 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 6 Sep 2006 11:09:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-476) DSL constraint
 appending needs to be tolerant of spaces
Message-ID: <28700414.1157555373009.JavaMail.jira@cloud.prod.atl2.jboss.com>

DSL constraint appending needs to be tolerant of spaces
-------------------------------------------------------

                 Key: JBRULES-476
                 URL: http://jira.jboss.com/jira/browse/JBRULES-476
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.4
            Reporter: Michael Neale
         Assigned To: Michael Neale


If you do

[when]-foo bar=Baz()

it will fail to expand unless you put a space after the "-".

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:09:33 2006
From: jira-events at jboss.com (Brice Ruth (JIRA))
Date: Wed, 6 Sep 2006 11:09:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-745) Add <action> to JPDL
 docs for create-timer
Message-ID: <19490009.1157555373312.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add <action> to JPDL docs for create-timer
------------------------------------------

                 Key: JBPM-745
                 URL: http://jira.jboss.com/jira/browse/JBPM-745
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Documentation
    Affects Versions:  jBPM 3.1.2, jBPM 3.1.1, jBPM 3.1
            Reporter: Brice Ruth
         Assigned To: Tom Baeyens
            Priority: Minor


See http://docs.jboss.org/jbpm/v3/userguide/jpdl.html#create.timer.element

Much the same as defining a <timer /> in jpdl, <create-timer></create-timer> supports a nested <action /> element. This should be appropriately referenced/linked in the documentation in this section.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:23:31 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:23:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-121) Check recovery
Message-ID: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>

Check recovery
--------------

                 Key: JBTM-121
                 URL: http://jira.jboss.com/jira/browse/JBTM-121
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:49:32 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:49:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-117) release notes for
 JTS talk about context interceptor
In-Reply-To: <4031051.1155223512756.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16274931.1157557772637.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-117?page=comments#action_12342951 ] 
            
Mark Little commented on JBTM-117:
----------------------------------

This is done in HEAD, just not in the branch.

> release notes for JTS talk about context interceptor
> ----------------------------------------------------
>
>                 Key: JBTM-117
>                 URL: http://jira.jboss.com/jira/browse/JBTM-117
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Should update to talk about interposition interceptor.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:49:32 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 11:49:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-38) Interoperability demo
Message-ID: <22910854.1157557772825.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-38?page=comments#action_12342952 ] 
            
Kevin Conner commented on JBTM-38:
----------------------------------

The work involved writing the following parts
 - the protocol supporting the WS-TX1.1 AT and Coordination specifications
 - a web application responsible for initiating the AT interop tests
 - a web service responsible for the participant side of the tests
 - an HTTP proxy responsible for logging and orchestrating some tests

All tests were successfully executed against the other organisations taking part in the interop.

> Interoperability demo
> ---------------------
>
>                 Key: JBTM-38
>                 URL: http://jira.jboss.com/jira/browse/JBTM-38
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>          Time Spent: 1 week, 4 days
>  Remaining Estimate: 0 minutes
>
> Demonstrate interoperability with IBM and Microsoft. Important for the specification as well as our product.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:51:28 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 11:51:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-38) Interoperability demo
Message-ID: <22227402.1157557888424.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-38?page=all ]

Kevin Conner closed JBTM-38.
----------------------------

    Resolution: Done

> Interoperability demo
> ---------------------
>
>                 Key: JBTM-38
>                 URL: http://jira.jboss.com/jira/browse/JBTM-38
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>          Time Spent: 1 week, 4 days
>  Remaining Estimate: 0 minutes
>
> Demonstrate interoperability with IBM and Microsoft. Important for the specification as well as our product.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:57:30 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-37) Modifications for the
 OASIS Standard
Message-ID: <33243128.1157558250827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-37?page=all ]

Mark Little updated JBTM-37:
----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)])
    Assignee: Kevin Conner  (was: Mark Little)

> Modifications for the OASIS Standard
> ------------------------------------
>
>                 Key: JBTM-37
>                 URL: http://jira.jboss.com/jira/browse/JBTM-37
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.4
>
>
> Preliminary support for the OASIS WS-TX standard.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:59:33 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:59:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-111) Check QA into CVS
In-Reply-To: <19381808.1154158031400.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18175359.1157558373940.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-111?page=all ]

Mark Little updated JBTM-111:
-----------------------------

    Fix Version/s: 4.6
                       (was: 4.4)

> Check QA into CVS
> -----------------
>
>                 Key: JBTM-111
>                 URL: http://jira.jboss.com/jira/browse/JBTM-111
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.6
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:59:34 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:59:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-108) Make number of
 transactions rolled back per reaper sweep configurable
In-Reply-To: <15698701.1154089451341.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6885444.1157558374053.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-108?page=all ]

Mark Little updated JBTM-108:
-----------------------------

    Fix Version/s: 4.6
                       (was: 4.4)

> Make number of transactions rolled back per reaper sweep configurable
> ---------------------------------------------------------------------
>
>                 Key: JBTM-108
>                 URL: http://jira.jboss.com/jira/browse/JBTM-108
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      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.6
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 11:59:34 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 6 Sep 2006 11:59:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-37) Modifications for the
 OASIS Standard
Message-ID: <9143827.1157558374231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-37?page=all ]

Mark Little updated JBTM-37:
----------------------------

    Fix Version/s: 4.6
                       (was: 4.4)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)])

> Modifications for the OASIS Standard
> ------------------------------------
>
>                 Key: JBTM-37
>                 URL: http://jira.jboss.com/jira/browse/JBTM-37
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.6
>
>
> Preliminary support for the OASIS WS-TX standard.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 12:01:30 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 12:01:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-122) Requalify WS-TX 1.0
 interop against IBM/Microsoft endpoints
Message-ID: <33145092.1157558490997.JavaMail.jira@cloud.prod.atl2.jboss.com>

Requalify WS-TX 1.0 interop against IBM/Microsoft endpoints
-----------------------------------------------------------

                 Key: JBTM-122
                 URL: http://jira.jboss.com/jira/browse/JBTM-122
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: WS-T Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 12:03:30 2006
From: jira-events at jboss.com (Colin Walters (JIRA))
Date: Wed, 6 Sep 2006 12:03:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-619) PojoCache to
 support JDK5.0 Enum
Message-ID: <24839643.1157558610658.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-619?page=comments#action_12342953 ] 
            
Colin Walters commented on JBCACHE-619:
---------------------------------------

So as I understand it, without this bug fix it is not possible to use enum values in entity objects
when using the EJB3 entity cache?

Is there a workaround?  

I found this JIRA from this forum thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=71311&view=previous

> PojoCache to support JDK5.0 Enum
> --------------------------------
>
>                 Key: JBCACHE-619
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-619
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 12:05:30 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 6 Sep 2006 12:05:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-37) Modifications for
 the OASIS Standard
Message-ID: <7982374.1157558730537.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-37?page=comments#action_12342954 ] 
            
Kevin Conner commented on JBTM-37:
----------------------------------

The protocol for the OASIS WS-TX 1.1 AtomicTransaction and Coordination specifications was written as part of JBTM-38.  This still has to be integrated into the current WS-TX implementation.

> Modifications for the OASIS Standard
> ------------------------------------
>
>                 Key: JBTM-37
>                 URL: http://jira.jboss.com/jira/browse/JBTM-37
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.6
>
>
> Preliminary support for the OASIS WS-TX standard.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 13:05:37 2006
From: jira-events at jboss.com (Antoine Herzog (JIRA))
Date: Wed, 6 Sep 2006 13:05:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5852451.1157562337100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12342959 ] 
            
Antoine Herzog commented on JBPORTAL-1004:
------------------------------------------

In the doc, it is said : rebuild the jboss portal to change the "portal" first item in the url.
Could be possible to do it more simply ?
when starting, we don't want to touch that. After trying the portal and build our environnement (cms configuration....) and new portlets, it seem heavy to rebuild from the begining.
May be only make some documentation about how to change thing without rebuilding the whole thing ?
(open another issue for this ?)


> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 14:05:34 2006
From: jira-events at jboss.com (Jerry Gauthier (JIRA))
Date: Wed, 6 Sep 2006 14:05:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-470) Update JBoss Cache
 to use JGroups 2.4 and Multiplexer
Message-ID: <22130465.1157565934531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-470?page=all ]

Jerry Gauthier closed JBCACHE-470.
----------------------------------

    Resolution: Done

Multiplexer integration has been enabled for JBossCache 2.0.  Documentation has been updated and sample configuration files have been modified to demonstrate how to configure the multiplxer with JBossCache.

> Update JBoss Cache to use JGroups 2.4 and Multiplexer
> -----------------------------------------------------
>
>                 Key: JBCACHE-470
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-470
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.2.4
>            Reporter: Manik Surtani
>         Assigned To: Jerry Gauthier
>            Priority: Blocker
>             Fix For: 2.0.0
>
>
> Use a ChannelFactory that looks up the MBean server to potentially create a JGroups multiplexer channel

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 14:23:29 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 6 Sep 2006 14:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-1) Move source
 repository from trunk to projects
In-Reply-To: <2995519.1157476652735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5726783.1157567009405.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-1?page=all ]

Anil Saldhana updated SECURITY-1:
---------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90069

> Move source repository from trunk to projects
> ---------------------------------------------
>
>                 Key: SECURITY-1
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-1
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Scott has expressed a desire to see the security project act as the model project to have a SPI and a JBossAS implementation. 
> The first step in this exercize is to move the source repository from jbossas/trunk  to https://svn.jboss.org/repos/jbossas/projects/  (Reference will be the microcontainer project)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:05:33 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Wed, 6 Sep 2006 15:05:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-190) web app generation
	tool
Message-ID: <29778645.1157569533527.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-190?page=comments#action_12342968 ] 
            
Alejandro Guizar commented on BPEL-190:
---------------------------------------

Actually, WSDL includes a binding for HTTP's GET and POST methods, so that apps other than web browsers are able to interact with a web site. This binding makes an html-based webapp a formal webservice. The ex-CEO probably did not realize how right he was :-)

The WSDL spec URL: http://www.w3.org/TR/wsdl#_http

As useful as it could be, potentially saving years of typing into HTML forms, it lacks support in WS stacks. Even Apache WSIF does not support the HTTP binding. Most works focus on the SOAP binding and leave other bindings out.

So many paths, so little time :-\

> web app generation tool
> -----------------------
>
>                 Key: BPEL-190
>                 URL: http://jira.jboss.com/jira/browse/BPEL-190
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 1
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> create a tool for generating web application artifacts

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:16:28 2006
From: jira-events at jboss.com (Jim Moran (JIRA))
Date: Wed, 6 Sep 2006 15:16:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3629)
 org.jboss.naming.ExternalContext.SerializableInitialContext should be
 included in [jboss]/client/jbossall-client.jar
Message-ID: <13965861.1157570188405.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.naming.ExternalContext.SerializableInitialContext should be included in [jboss]/client/jbossall-client.jar
--------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3629
                 URL: http://jira.jboss.com/jira/browse/JBAS-3629
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Build System, Naming
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Jim Moran
         Assigned To: Ruel Loehr
            Priority: Minor


org.jboss.naming.ExternalContext.SerializableInitialContext exists in server/default/lib/jboss.jar but it does not exist for a client that uses [jboss]/client/jbossall-client.jar.
As a result if a client app needs to lookup an ExternalContext on a remote JBoss instance, the client must enable RMI classloader or include server/default/lib/jboss.jar
It would be nicer if ExternalContext was included with jbossall-client.jar

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:36:28 2006
From: jira-events at jboss.com (Stephen Parry (JIRA))
Date: Wed, 6 Sep 2006 15:36:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-361) When creating entity
 bean, multiple radio buttons from the same group are checked
Message-ID: <33423178.1157571388696.JavaMail.jira@cloud.prod.atl2.jboss.com>

When creating entity bean, multiple radio buttons from the same group are checked
---------------------------------------------------------------------------------

                 Key: JBIDE-361
                 URL: http://jira.jboss.com/jira/browse/JBIDE-361
             Project: JBoss IDE
          Issue Type: Bug
    Affects Versions: 1.6
         Environment: Windows XP SP2 JBoss 4.0.4 GA Eclipse 3.1.2 IDE 1.6.0 from update site
            Reporter: Stephen Parry


- Added new J2EE 1.4 project JiraTest with source folder src with output bin
- Added new package: jiratest.ejb
- Right click on package, select New -> Other -> Entity Bean
New Entity Bean wizard appears, but the radio buttons are 'confused'; both CMP 1.x and CMP 2.x are selected and both Remote and Local are selected, but not Both (!).


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:48:29 2006
From: jira-events at jboss.com (Todd Main (JIRA))
Date: Wed, 6 Sep 2006 15:48:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-343) Action method of
 source page being executed after destination action
Message-ID: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>

Action method of source page being executed after destination action
--------------------------------------------------------------------

                 Key: JBSEAM-343
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
             Project: JBoss Seam
          Issue Type: Bug
          Components: JSF
    Affects Versions: 1.0.1
         Environment: Windows XP, jboss installation per Seam setup instructions
            Reporter: Todd Main


I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:

Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".

   <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>

There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.

                            <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
                                <f:param name="dayRange" value="7" />
                                <f:param name="documentCategory" value="po" />
                                #{quickClicksData.ordersFromLastSeven}
                            </s:link>

When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.

Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:

This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is

Code:

   
   public boolean callPageActions(PhaseEvent event)
   {
      Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
      boolean actionsWereCalled = false;
      try
      {
         actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
         actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
         return actionsWereCalled;

The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.

If the code were
Code:

    actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
    actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
    return actionsWereCalled;
	


that should fix this.


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 15:50:29 2006
From: jira-events at jboss.com (Mauro Lopez (JIRA))
Date: Wed, 6 Sep 2006 15:50:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-344) Portal booking
 example loses conversation after validation error
Message-ID: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portal booking example loses conversation after validation error
----------------------------------------------------------------

                 Key: JBSEAM-344
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
             Project: JBoss Seam
          Issue Type: Bug
          Components: Portal
    Affects Versions: 1.0.1
         Environment: JBoss 4.0.4.GA
JBoss Portal 2.4.0-Beta1
(used jems-installer-1.2.0.BETA)
JBoss Seam 1.0.1.GA
            Reporter: Mauro Lopez


Followed this steps:
- deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
- Entered http://localhost:8080/portal
- Selected the SeamHibernate portlet tab, registered user, logged in...
- Searched hotels, selected one of them, and pressed the "Book" button.

In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 

So, after a failed validation, the conversation is lost.

In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 16:22:38 2006
From: jira-events at jboss.com (Chris Mercer (JIRA))
Date: Wed, 6 Sep 2006 16:22:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-6) Archive Browser
 does not support jar:file: url protocol
Message-ID: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>

Archive Browser does not support jar:file: url protocol
-------------------------------------------------------

                 Key: JBCOMMON-6
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-6
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: core
         Environment: jdk 1.5.8
jboss 4.0.4ga
hibernate 3.2cr2
hibernate entity manager 3.2.0.CR1
Using ejb3/entity manager annotations
            Reporter: Chris Mercer
         Assigned To: Dimitris Andreadis
            Priority: Critical


We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.


Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
	... 148 more


org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  

This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  

I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 16:22:38 2006
From: jira-events at jboss.com (Chris Mercer (JIRA))
Date: Wed, 6 Sep 2006 16:22:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-7) Archive Browser
 does not support jar:file: url protocol
Message-ID: <13191915.1157574158355.JavaMail.jira@cloud.prod.atl2.jboss.com>

Archive Browser does not support jar:file: url protocol
-------------------------------------------------------

                 Key: JBCOMMON-7
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-7
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: core
         Environment: jdk 1.5.8
jboss 4.0.4ga
hibernate 3.2cr2
hibernate entity manager 3.2.0.CR1
Using ejb3/entity manager annotations
            Reporter: Chris Mercer
         Assigned To: Dimitris Andreadis
            Priority: Critical


We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.


Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
	... 148 more


org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  

This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  

I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 16:26:28 2006
From: jira-events at jboss.com (Chris Mercer (JIRA))
Date: Wed, 6 Sep 2006 16:26:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-7) Archive Browser does
 not support jar:file: url protocol
In-Reply-To: <13191915.1157574158355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30188855.1157574388894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-7?page=all ]

Chris Mercer closed JBCOMMON-7.
-------------------------------

    Resolution: Duplicate Issue

submitted twice on accident

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: JBCOMMON-7
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-7
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:04:29 2006
From: jira-events at jboss.com (David Green (JIRA))
Date: Wed, 6 Sep 2006 17:04:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-698) Exception
 serialization issue when remotely accessing stateless session bean
Message-ID: <23517647.1157576669733.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception serialization issue when remotely accessing stateless session bean
----------------------------------------------------------------------------

                 Key: EJBTHREE-698
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-698
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: David Green


Accessing a remote EJB (Session bean) results in exception.  Stack trace follows:

13:54:39,546 ERROR [SocketClientInvoker] Got marshalling exception, exiting
java.lang.ClassNotFoundException: [Ljava.lang.StackTraceElement;
	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
	at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:50)
	at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:139)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
	at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1624)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1945)
	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1869)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)
	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128)
	at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66)
	at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279)
	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
	at org.jboss.remoting.Client.invoke(Client.java:525)
	at org.jboss.remoting.Client.invoke(Client.java:488)
	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:65)
	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
	at $Proxy0.postNotification(Unknown Source)
	at com.hgea.hch.service.HchClientDelegate.postNotification(HchClientDelegate.java:99)
	at com.hgea.hch.client.RemoteHchClientTest.testRemotePostNotification(RemoteHchClientTest.java:38)
	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:597)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:297)
	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672)
	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:18:32 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 6 Sep 2006 17:18:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
In-Reply-To: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15451824.1157577512202.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-299?page=all ]

Bela Ban resolved JGRP-299.
---------------------------

    Resolution: Done

Looks like your JVM doesn't support setting this option. I therefore recommend you remove the tos="8" line from your config file

> NotificationBusDemo problem with 2.4CR2
> ---------------------------------------
>
>                 Key: JGRP-299
>                 URL: http://jira.jboss.com/jira/browse/JGRP-299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: MacOSX, Java 1.5
>            Reporter: Christian Pekeler
>         Assigned To: Bela Ban
>
> [/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
> Starting NotificationBus with name BusDemo
> Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
> INFO: JGroups version: 2.4CR2
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> INFO: sockets will use interface 192.168.5.142
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:24:30 2006
From: jira-events at jboss.com (Christian Pekeler (JIRA))
Date: Wed, 6 Sep 2006 17:24:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
In-Reply-To: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27778124.1157577870531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-299?page=comments#action_12342976 ] 
            
Christian Pekeler commented on JGRP-299:
----------------------------------------

It did work without error on my JVM (Java 1.5 on Mac OS X 10.4.7) with 2.4CR1 and earlier versions.

> NotificationBusDemo problem with 2.4CR2
> ---------------------------------------
>
>                 Key: JGRP-299
>                 URL: http://jira.jboss.com/jira/browse/JGRP-299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: MacOSX, Java 1.5
>            Reporter: Christian Pekeler
>         Assigned To: Bela Ban
>
> [/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
> Starting NotificationBus with name BusDemo
> Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
> INFO: JGroups version: 2.4CR2
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> INFO: sockets will use interface 192.168.5.142
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 17:44:28 2006
From: jira-events at jboss.com (Antoine Herzog (JIRA))
Date: Wed, 6 Sep 2006 17:44:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32546559.1157579068483.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12342977 ] 
            
Antoine Herzog commented on JBPORTAL-1004:
------------------------------------------

It is in the documentation of 2.4. 
this comment is useless. sorry.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:31 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <25867620.1157580031568.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment:     (was: new_splash_left_aligned.jpg)

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:31 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <25669011.1157580031733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment: ide_spotlight_v3progress.jpg

OK, we got the new image that covers the new product name "JBossIDE for Eclipse" and includes good spacing/alignment for the progress bar and loading message. Check out the attached JPG.. looks nice and pretty =). Issue should now be considered resolved..

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:31 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <16643286.1157580031938.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper resolved JBIDE-332.
--------------------------------------

    Fix Version/s: 2.0.0.Beta2
       Resolution: Done

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:32 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <13808712.1157580032102.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment:     (was: ide_spotlight_v3progress.jpg)

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:00:32 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Wed, 6 Sep 2006 18:00:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBIDE-332) Create a new splash
 image for JBossIDE 2.0
Message-ID: <1213257.1157580032265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-332?page=all ]

Marshall Culpepper updated JBIDE-332:
-------------------------------------

    Attachment: new_splash_left_aligned.jpg

> Create a new splash image for JBossIDE 2.0
> ------------------------------------------
>
>                 Key: JBIDE-332
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-332
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossIDE-splash.xcf, new_splash_left_aligned.jpg
>
>
> We need a new splash screen for JBossIDE 2.0...
> Preferrably the size shouldn't be bigger than 455x295. I've attached the splash screen we were using for 1.5 and 1.6 (it's in Gimp/XCF format)

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:44:43 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 6 Sep 2006 18:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1023) Use cookies to
 deal with sessions instead of SessionContext
Message-ID: <31796742.1157582683797.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use cookies to deal with sessions instead of SessionContext
-----------------------------------------------------------

                 Key: JBPORTAL-1023
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1023
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep  6 18:44:43 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 6 Sep 2006 18:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1023) Use cookies to
 deal with sessions instead of SessionContext
In-Reply-To: <31796742.1157582683797.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30928461.1157582683866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1023?page=all ]

Chris Laprun resolved JBPORTAL-1023.
------------------------------------

    Fix Version/s: 2.6.Alpha1
       Resolution: Done

> Use cookies to deal with sessions instead of SessionContext
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1023
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1023
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:03:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 19:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-424) Cannot
 access the first message when starting the JMS subscriber
Message-ID: <4355164.1157583823765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-424?page=comments#action_12342983 ] 
            
Clebert Suconic commented on JBMESSAGING-424:
---------------------------------------------

I have added org.jboss.test.messaging.jms.crash.DurableCrash1 and org.jboss.test.messaging.jms.crash.DurableCrash2.

To execute this combined test, execute ant crash-tests on testsuite. (when I posted this commented it was commited on Branch_1 only, I will commit it to Trunk as soon as we decide the test is valid)

> Cannot access the first message when starting the JMS subscriber
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-424
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-424
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: JBoss jboss-4.0.4.GA & jboss-messaging-1.0.1.CR2 
>            Reporter: Seung Hyun
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Some messages are already published to the specific queue and the queue contains few messages. Starts the subscriber to receive the messages in the queue. It reads all the messages except the first message. Also, the first message is not accessible at all.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:03:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 6 Sep 2006 19:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-424) Cannot access
 the first message when starting the JMS subscriber
Message-ID: <21384372.1157583823914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-424?page=all ]

Clebert Suconic updated JBMESSAGING-424:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> Cannot access the first message when starting the JMS subscriber
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-424
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-424
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: JBoss jboss-4.0.4.GA & jboss-messaging-1.0.1.CR2 
>            Reporter: Seung Hyun
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Some messages are already published to the specific queue and the queue contains few messages. Starts the subscriber to receive the messages in the queue. It reads all the messages except the first message. Also, the first message is not accessible at all.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:07:27 2006
From: jira-events at jboss.com (Ivelin Ivanov (JIRA))
Date: Wed, 6 Sep 2006 19:07:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <16090713.1157584047380.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342984 ] 
            
Ivelin Ivanov commented on JBAS-3345:
-------------------------------------

great. let's make the switch.


> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:21:27 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Wed, 6 Sep 2006 19:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-350) create
 specification for jbossws/jbosside plugin / integration
In-Reply-To: <30880297.1155172032601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6619104.1157584887930.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-350?page=comments#action_12342985 ] 
            
Max Andersen commented on JBIDE-350:
------------------------------------

i'm a WS noob, but one thing I definitly would "assume" is that we would hook into/support WTP WS integration....and if not at least find out why it can't/won't be done ;)

> create specification for jbossws/jbosside plugin / integration
> --------------------------------------------------------------
>
>                 Key: JBIDE-350
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-350
>             Project: JBoss IDE
>          Issue Type: Task
>          Components: Webservices Plugin
>            Reporter: Ole Matzura
>         Assigned To: Ole Matzura
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossWS Eclipse Plugin Specification.doc
>
>
> we need a spec that outlines how jbossws should be integrated into eclipse/jbosside

-- 
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

        


From jira-events at jboss.com  Wed Sep  6 19:54:43 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Wed, 6 Sep 2006 19:54:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <33174856.1157586883946.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12342986 ] 
            
Remy Maucherat commented on JBAS-3345:
--------------------------------------

There are indeed some testsuite issues.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 02:39:26 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 02:39:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-299) NotificationBusDemo
 problem with 2.4CR2
In-Reply-To: <20168486.1157497963971.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4106313.1157611166630.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-299?page=comments#action_12342999 ] 
            
Bela Ban commented on JGRP-299:
-------------------------------

Then try setting it to back to 16

> NotificationBusDemo problem with 2.4CR2
> ---------------------------------------
>
>                 Key: JGRP-299
>                 URL: http://jira.jboss.com/jira/browse/JGRP-299
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: MacOSX, Java 1.5
>            Reporter: Christian Pekeler
>         Assigned To: Bela Ban
>
> [/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo 
> Starting NotificationBus with name BusDemo
> Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
> INFO: JGroups version: 2.4CR2
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> INFO: sockets will use interface 192.168.5.142
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
> WARNING: traffic class of 8 could not be set, will be ignored
> java.net.SocketException: Invalid argument
>         at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
>         at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
>         at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
>         at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
>         at org.jgroups.protocols.UDP.start(UDP.java:383)
>         at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
>         at org.jgroups.stack.DownHandler.run(Protocol.java:118)
> Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:19:28 2006
From: jira-events at jboss.com (Maurice Zeijen (JIRA))
Date: Thu, 7 Sep 2006 03:19:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-345) correct ejb-jar.xml
 root node declaration in examples
Message-ID: <16305010.1157613568524.JavaMail.jira@cloud.prod.atl2.jboss.com>

correct ejb-jar.xml root node declaration in examples
-----------------------------------------------------

                 Key: JBSEAM-345
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-345
             Project: JBoss Seam
          Issue Type: Task
          Components: Examples
    Affects Versions: 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1, 1.1
            Reporter: Maurice Zeijen
            Priority: Minor


Please correct the root node decleration in the seam examples. At this moment they only contain the <ejb-jar> node but this should be:

<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.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

        


From jira-events at jboss.com  Thu Sep  7 03:19:28 2006
From: jira-events at jboss.com (Stephen Friedrich (JIRA))
Date: Thu, 7 Sep 2006 03:19:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-346) Full <ejb-jar>
 declaration in examples' ejb-jar.xml files
Message-ID: <27019148.1157613568758.JavaMail.jira@cloud.prod.atl2.jboss.com>

Full <ejb-jar> declaration in examples' ejb-jar.xml files
---------------------------------------------------------

                 Key: JBSEAM-346
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-346
             Project: JBoss Seam
          Issue Type: Task
          Components: Examples
    Affects Versions: 1.0.1
            Reporter: Stephen Friedrich


Currently ejb-jar.xml files in seam examples (1.0.1 GA) use just "<ejb-jar>".

Would be nicer if they used a full, standard compliant declaration:
{code}
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
         version="3.0">	
{code}

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:37:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 03:37:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-300) NAKACK.send() doesn't
 need to be synchronized
Message-ID: <9351729.1157614648499.JavaMail.jira@cloud.prod.atl2.jboss.com>

NAKACK.send() doesn't need to be synchronized
---------------------------------------------

                 Key: JGRP-300
                 URL: http://jira.jboss.com/jira/browse/JGRP-300
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.4


NAKACK.send() currently calls passDown(evt) in a synchronized(sent_msgs) statement. However, this is not necessary (contrary to handleMessage() which needs to pass messages up in the order of sequence numbers) because messages can be sent un-ordered. The receivers will order the messages anyway, so if we sent 1,3,2,4 due to thread premption, the receivers will order them and deliver them as 1,2,3,4.
BENEFIT: the less synchronization, the less probability of deadlocks

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:41:29 2006
From: jira-events at jboss.com (Maurice Zeijen (JIRA))
Date: Thu, 7 Sep 2006 03:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
Message-ID: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
------------------------------------------------------------------------------------

                 Key: JBSEAM-347
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.1, 1.0, 1.0 beta 2, 1.0 beta 1, 1.1
         Environment: JBoss 4.0.4 GA
JBoss Portal 2.4
MyFaces 1.1.3
            Reporter: Maurice Zeijen
            Priority: Critical


I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 

My configuration details are below the exception.

Code:

23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
java.lang.IllegalStateException: No active session context
	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
agedPersistencePortletPhaseListener.java:53)
	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
.java:89)
	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)

	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)

	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
va:143)
	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
ceptor.java)
	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
r.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
java:55)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
SessionSynchronizationInterceptor.java:76)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
ContextDispatcherInterceptor.java:124)
	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
rInterceptor.java:68)
	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
terceptor.java:74)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
tor.java:50)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
eptor.java:65)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
14)
	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy65.invoke(Unknown Source)
	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
a:249)
	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy67.invoke(Unknown Source)
	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
rvice.java:139)
	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
Service.java:155)
	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy69.invoke(Unknown Source)
	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
ssionSynchronizationInterceptor.java:85)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
r.java:93)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
tor.java:83)
	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy51.invoke(Unknown Source)
	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
rceptor.java:171)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
tor.java:80)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
terceptor.java:79)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
:59)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
rceptor.java:171)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
tor.java:80)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
terceptor.java:79)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
:59)
	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
va:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
	at $Proxy161.handle(Unknown Source)
	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
4)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
:65)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
terceptor.java:92)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
$TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
xt(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
xt(TransactionInterceptor$invoke_N5143606530999904530.java)
	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)

	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
Protocol.java:664)
	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
	at java.lang.Thread.run(Thread.java:595)


Here are the config files:

Components.xml
Code:

<components>

    <component name="org.jboss.seam.core.init">
    	<property name="debug">true</property>
        <property name="myFacesLifecycleBug">false</property>
        <property name="jndiPattern">@jndiPattern@</property>
    </component>
    
    <!-- 120 second conversation timeout -->
    <component name="org.jboss.seam.core.manager">
        <property name="conversationTimeout">120000</property>
    </component>
    
    <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>

</components>
	



components.properties
Code:

embeddedEjb false
jndiPattern TestPortlet/#{ejbName}/local
	



faces-config.xml
Code:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE faces-config 
    PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
    "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">

<faces-config>

	<!-- Navigation rules for the Booking demo app -->
	
	<navigation-rule>
		<from-view-id>*</from-view-id>
		<navigation-case>
			<from-outcome>view</from-outcome>
			<to-view-id>/view.xhtml</to-view-id>
		</navigation-case>
	</navigation-rule>
	
	<navigation-rule>
		<from-view-id>*</from-view-id>
		<navigation-case>
			<from-outcome>edit</from-outcome>
			<to-view-id>/edit.xhtml</to-view-id>
		</navigation-case>
	</navigation-rule>
	
	<navigation-rule>
		<from-view-id>*</from-view-id>
		<navigation-case>
			<from-outcome>help</from-outcome>
			<to-view-id>/help.xhtml</to-view-id>
		</navigation-case>
	</navigation-rule>

	<application>
		<view-handler>
			com.sun.facelets.FaceletPortletViewHandler
		</view-handler>
	</application>

	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->

	<lifecycle>
		<phase-listener>
			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
		</phase-listener>
	</lifecycle>

</faces-config>
	



web.xml
Code:

<?xml version="1.0" encoding="UTF-8"?>
<web-app> 

	 <!-- ### Seam  ######################################################################################
######### -->
   
    <listener>
        <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
    </listener>
	
    <!-- Propagate conversations across redirects -->
    <filter>
        <filter-name>Seam Redirect Filter</filter-name>
        <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
    </filter>
    
    <filter-mapping>
        <filter-name>Seam Redirect Filter</filter-name>
        <url-pattern>*.seam</url-pattern>
    </filter-mapping>
    
    <filter-mapping>
        <filter-name>Seam Redirect Filter</filter-name>
        <url-pattern>*.xhtml</url-pattern>
    </filter-mapping>
    
    <!-- ### JSF ########################################################################################
####### -->
    
    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>client</param-value>
    </context-param>

    <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
    </context-param>

    <context-param>
        <param-name>facelets.DEVELOPMENT</param-name>
        <param-value>true</param-value>
    </context-param>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
	
	 <!-- ### MY FACES ###################################################################################
############ -->
    
	
	<context-param>
		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
		<param-value>true</param-value>
		<description>
		    This parameter tells MyFaces if javascript code should be allowed in the
		    rendered HTML output.
		    If javascript is allowed, command_link anchors will have javascript code
		    that submits the corresponding form.
		    If javascript is not allowed, the state saving info and nested parameters
		    will be added as url parameters.
		    Default: "true"
		    </description>
	</context-param>

	<context-param>
		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
		<param-value>false</param-value>
		<description>
		    This parameter tells MyFaces if javascript code should be allowed in the
		    rendered HTML output.
		    If javascript is allowed, command_link anchors will have javascript code
		    that submits the corresponding form.
		    If javascript is not allowed, the state saving info and nested parameters
		    will be added as url parameters.
		    Default: "false"
	
		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
		    best results.
	
		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
low to get
		    JavaScript detection working.
		    </description>
	</context-param>

	<context-param>
		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
		<param-value>true</param-value>
		<description>
		    If true, rendered HTML code will be formatted, so that it is "human readable".
		    i.e. additional line separators and whitespace will be written, that do not
		    influence the HTML code.
		    Default: "true"
		</description>
	</context-param>

	<context-param>
		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
		<param-value>true</param-value>
		<description>
		    If true, a javascript function will be rendered that is able to restore the
		    former vertical scroll on every request. Convenient feature if you have pages
		    with long lists and you do not want the browser page to always jump to the top
		    if you trigger a link or button action that stays on the same page.
		    Default: "false"
		</description>
	</context-param>

    <!-- Extensions Filter -->
	<filter>
		<filter-name>extensionsFilter</filter-name>
		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
		<init-param>
			<param-name>uploadMaxFileSize</param-name>
			<param-value>100m</param-value>
			<description>
				Set the size limit for uploaded files.
				Format: 10 - 10 bytes
					10k - 10 KB
					10m - 10 MB
					1g - 1 GB
			</description>
		</init-param>
		<init-param>
			<param-name>uploadThresholdSize</param-name>
			<param-value>100k</param-value>
			<description>
				Set the threshold size - files below this limit are stored in memory, files above
				this limit are stored on disk.
	
				Format: 10 - 10 bytes
					10k - 10 KB
					10m - 10 MB
					1g - 1 GB
			</description>
		</init-param>
	</filter>

    <!-- ### Faces Servlet Mapping  #####################################################################
########################## -->
    
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.seam</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>

</web-app>

	




The portlet implementation of the FaceletsViewHandler
Code:

package com.sun.facelets;

import java.io.IOException;

import javax.faces.FacesException;
import javax.faces.application.ViewHandler;
import javax.faces.context.ExternalContext;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.render.RenderKit;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;

/**
 * ViewHandler implementation for Facelets used in Portlets
 * 
 */
public class FaceletPortletViewHandler extends FaceletViewHandler {
	 public FaceletPortletViewHandler(ViewHandler parent) {
	        super(parent);
	    }

	    protected ResponseWriter createResponseWriter(FacesContext context)
	            throws IOException, FacesException {
	        ExternalContext extContext = context.getExternalContext();
	        RenderKit renderKit = context.getRenderKit();

	        RenderRequest request = (RenderRequest) extContext.getRequest();
	        RenderResponse response = (RenderResponse) extContext.getResponse();

	        String contenttype = request.getResponseContentType();
	        if (contenttype == null) {
	            contenttype = "text/html";
	        }

	        String encoding = response.getCharacterEncoding();
	        if (encoding == null) {
	            encoding = "ISO-8859-1";
	        }

	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
coding);

	        contenttype = writer.getContentType();

	        // apply them to the response
	        response.setContentType(contenttype);

	        // Now, clone with the real writer
	        writer = writer.cloneWithWriter(response.getWriter());

	        return writer;
	    }

}

	



Special version of the MyFaceGenericPortlet.
Code:

/**
 * 
 */
package com.smies.portlet;

import java.io.IOException;
import java.util.Enumeration;

import javax.portlet.PortletException;
import javax.portlet.PortletMode;
import javax.portlet.PortletSession;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.portlet.UnavailableException;

/**
 * 
 */
public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {

	private String viewPage = null;
	private String editPage = null;
	private String helpPage = null;
	
	public void init() throws UnavailableException, PortletException {
		viewPage = (String) this.getInitParameter("ViewPage");
		editPage = (String) this.getInitParameter("EditPage");
		helpPage = (String) this.getInitParameter("HelpPage");
		super.init();
	}
	
	public void render(RenderRequest request, RenderResponse response)
			throws PortletException, IOException {

		PortletSession session = request.getPortletSession();
		PortletMode mode = (PortletMode) session
				.getAttribute("CurrentPortletMode");

		if (mode == null) {
			mode = request.getPortletMode();
		}

		if (mode != request.getPortletMode()) {
			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
		} else {
			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
		}

		session.setAttribute("CurrentPortletMode", mode);
		super.render(request, response);
	}
	
	protected void setDefaultView() throws UnavailableException {
        this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
        if (defaultView == null) {
        	this.defaultView = this.viewPage;
        }
        if (defaultView == null) {
            String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
            throw new UnavailableException(msg);
        }
    }

	protected void doEdit(RenderRequest request, RenderResponse response)
			throws PortletException, IOException {

		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
		if (isPortletModeChanged.booleanValue()) {
			setPortletRequestFlag(request);
			nonFacesRequest(request, response, editPage);
			return;
		}

		facesRender(request, response);
	}

	protected void doHelp(RenderRequest request, RenderResponse response)
			throws PortletException, IOException {

		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
		if (isPortletModeChanged.booleanValue()) {
			setPortletRequestFlag(request);
			nonFacesRequest(request, response, helpPage);
			return;
		}

		facesRender(request, response);
	}

}

	




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 03:57:30 2006
From: jira-events at jboss.com (Penkov Vladimir (JIRA))
Date: Thu, 7 Sep 2006 03:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-665) @PostConstruct
 throws NPE when EntityManager is used
In-Reply-To: <24188502.1153922291327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24586971.1157615850341.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-665?page=comments#action_12343001 ] 
            
Penkov Vladimir commented on EJBTHREE-665:
------------------------------------------

got the same problem

Fedora Core 5
jboss-4.0.4.GA-patch1 + EJB3.0-RC8

> @PostConstruct throws NPE when EntityManager is used
> ----------------------------------------------------
>
>                 Key: EJBTHREE-665
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-665
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: Windows XP, JBoss 4.0.4.GA + EJB-3.0-RC8
>            Reporter: Steven Verze
>
> @PostConstruct method throws NPE when called on a stateless session bean.
> The method iteself accesses the enetity manager and tries create a query, the following exception is experienced:
> java.lang.RuntimeException: java.lang.NullPointerException
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:109)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:163)
> 	at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:125)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceBean.initialiseSpendCardQuery(SnapAccountSendProcessServiceBean.java:83)
> 	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.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:159)
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:105)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
> 	at $Proxy3.getBatchNumbers(Unknown Source)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceTest.testGetBatchNumbers(SnapAccountSendProcessServiceTest.java:57)
> 	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 junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Here is a the post construct method:
> @PostConstruct
>     void initialiseSpendCardQuery()
> 	{		
> 		StringBuilder sendCardQueryString = new StringBuilder();    	
> 		sendCardQueryString.append("SELECT c FROM Card AS c WHERE c.status = 'U' AND c.batchNumber IN (");
> 		 
> 		long[] batchNumbers = getBatchNumbers();
> 		for (int i = 0; i < batchNumbers.length; i++)
> 		{
> 		    sendCardQueryString.append("?").append(i);
> 			if (i+1 < batchNumbers.length)
> 			    sendCardQueryString.append(",");
> 		}
> 		sendCardQueryString.append(") AND c NOT IN (SELECT lc.sendCard FROM SendCardLock AS lc)");
> 		sendCardQuery = entityManager.createQuery(sendCardQueryString.toString());
> 		 
> 		for (int i = 0; i < batchNumbers.length; i++)
> 			sendCardQuery.setParameter(i, batchNumbers[i]);		
> 	}
> It happens when the entityManager is used.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:13:30 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Thu, 7 Sep 2006 04:13:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-301) Group partition when
 processes start almost same time
Message-ID: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>

Group partition when processes start almost same time
-----------------------------------------------------

                 Key: JGRP-301
                 URL: http://jira.jboss.com/jira/browse/JGRP-301
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.4
         Environment: Window XP
            Reporter: Sammi Ting
         Assigned To: Bela Ban
            Priority: Minor


There are 4 processes named A, B, C, D which should be join in a same group

Startup Sequence: A->B->C-D

Scenario:
1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
2. A join group with itself only (from log file on A, never see B, C, D)
3. B, C, D joined group together (from log files on B, C, D, never can see A)
4. Wait for long time A still in a single group


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:13:30 2006
From: jira-events at jboss.com (Stephen Friedrich (JIRA))
Date: Thu, 7 Sep 2006 04:13:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-265) Inject via method
	parameters
Message-ID: <25702530.1157616810813.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-265?page=comments#action_12343002 ] 
            
Stephen Friedrich commented on JBSEAM-265:
------------------------------------------

I don't grok this: At first I thought it's nice to use params instead of fields just to keep everything in as narrow scope as possible.
But who is going to call this method?
>From Java code I still need to pass an argument. If I do so, is it overriden by the context variable?
If, however I call this method from JSF expressions - well I could simply reference the user context variable in the call instead.

Probably I am missing the point...

> Inject via method parameters
> ----------------------------
>
>                 Key: JBSEAM-265
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-265
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>
> public void login(@In("user") User user) {
>    ...
> }
> is ugly, but we should support it anyway.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:25:26 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 04:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-301) Group partition
 when processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17811821.1157617526841.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-301?page=comments#action_12343003 ] 
            
Bela Ban commented on JGRP-301:
-------------------------------

Stack configuration ?
JGroups version ?

This is one of the most frequently tested scenarios (JGroups/doc/tests/GmsTests.txt), more likely it is a network issue. Next time, could you please discuss this on the mailing lists before opening a JIRA issue ?

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:25:26 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 04:25:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-301) Group partition when
 processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28672172.1157617526988.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-301?page=all ]

Bela Ban updated JGRP-301:
--------------------------

    Fix Version/s: 2.4

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:33:28 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Thu, 7 Sep 2006 04:33:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-746) replace
 NullPointerExceptions with JbpmExceptions
Message-ID: <24411573.1157618008353.JavaMail.jira@cloud.prod.atl2.jboss.com>

replace NullPointerExceptions with JbpmExceptions
-------------------------------------------------

                 Key: JBPM-746
                 URL: http://jira.jboss.com/jira/browse/JBPM-746
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:35:28 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Thu, 7 Sep 2006 04:35:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-746) replace
 NullPointerExceptions with JbpmExceptions
In-Reply-To: <24411573.1157618008353.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18884562.1157618128616.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-746?page=all ]

Tom Baeyens updated JBPM-746:
-----------------------------

    Description: replace the NPE's thrown by jbpm with JbpmExceptions.

> replace NullPointerExceptions with JbpmExceptions
> -------------------------------------------------
>
>                 Key: JBPM-746
>                 URL: http://jira.jboss.com/jira/browse/JBPM-746
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 1, jBPM 3.1.3
>
>
> replace the NPE's thrown by jbpm with JbpmExceptions.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:49:28 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Thu, 7 Sep 2006 04:49:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3630) JMSTransportSupport
 is not portable across different JMS providers.
Message-ID: <32915025.1157618968630.JavaMail.jira@cloud.prod.atl2.jboss.com>

JMSTransportSupport is not portable across different JMS providers.
-------------------------------------------------------------------

                 Key: JBAS-3630
                 URL: http://jira.jboss.com/jira/browse/JBAS-3630
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Darran Lofthouse
         Assigned To: Thomas Diesler
             Fix For: JBossAS-4.0.6.CR1


JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -

String fromName = null;
         Destination destination = message.getJMSDestination();
         if (destination instanceof Queue)
            fromName = "queue/" + ((Queue)destination).getQueueName();
         if (destination instanceof Topic)
            fromName = "topic/" + ((Topic)destination).getTopicName();

For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.

The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -

http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html

A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:51:27 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Thu, 7 Sep 2006 04:51:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3630) JMSTransportSupport
 is not portable across different JMS providers.
In-Reply-To: <32915025.1157618968630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12722656.1157619087585.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3630?page=all ]

Darran Lofthouse reassigned JBAS-3630:
--------------------------------------

    Assignee: Darran Lofthouse  (was: Thomas Diesler)

> JMSTransportSupport is not portable across different JMS providers.
> -------------------------------------------------------------------
>
>                 Key: JBAS-3630
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3630
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
> String fromName = null;
>          Destination destination = message.getJMSDestination();
>          if (destination instanceof Queue)
>             fromName = "queue/" + ((Queue)destination).getQueueName();
>          if (destination instanceof Topic)
>             fromName = "topic/" + ((Topic)destination).getTopicName();
> For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
> The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
> http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
> A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:53:29 2006
From: jira-events at jboss.com (Sammi Ting (JIRA))
Date: Thu, 7 Sep 2006 04:53:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-301) Group partition
 when processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17307994.1157619209493.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-301?page=comments#action_12343004 ] 
            
Sammi Ting commented on JGRP-301:
---------------------------------

Version: 2.4CR1

All processes use same configuration:

<config>
    <TCP start_port="8000" loopback="true" send_buf_size="100000" recv_buf_size="200000" enable_diagnostics="false"/>
    <TCPPING timeout="3000" initial_hosts="localhost[8000]" port_range="4" num_initial_members="4"/>
    <FD timeout="2000" max_tries="4"/>
    <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/>
    <pbcast.NAKACK gc_lag="100" retransmit_timeout="600,1200,2400,4800"/>
    <pbcast.STABLE stability_delay="500" desired_avg_gossip="20000" down_thread="false" max_bytes="40000000" up_thread="false"/>
    <VIEW_SYNC avg_send_interval="60000" down_thread="false" up_thread="false" />
    <pbcast.GMS print_local_addr="true" join_timeout="5000" join_retry_timeout="2000" shun="true"/>
</config>

All processes are seperate JVM under same machine. I just open different consoles for testing failover and found there are group partitions.

I just know there is such forum in sourceforge. I will switch my focus to there see if solution right there.

Thanks.

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 04:59:28 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Thu, 7 Sep 2006 04:59:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3630) JMSTransportSupport
 is not portable across different JMS providers.
In-Reply-To: <32915025.1157618968630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11913830.1157619568540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3630?page=all ]

Darran Lofthouse updated JBAS-3630:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90134

> JMSTransportSupport is not portable across different JMS providers.
> -------------------------------------------------------------------
>
>                 Key: JBAS-3630
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3630
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> JMSTransportSupport is not portable across different JMS providers, the queue name is retrieved using the following code: -
> String fromName = null;
>          Destination destination = message.getJMSDestination();
>          if (destination instanceof Queue)
>             fromName = "queue/" + ((Queue)destination).getQueueName();
>          if (destination instanceof Topic)
>             fromName = "topic/" + ((Topic)destination).getTopicName();
> For JBossMQ this is fine and it results in a name that matches the JNDI name of the queue, for WebSphereMQ this returns the name of the queue as configured on WebSphere not the JNDI name the queue is bound to in JBoss.
> The Javadoc for Queue describes the getQueueName as not being suitable for portable clients: -
> http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Queue.html
> A more portable solution could be to lookup a variable in the ENC that contains the name of the web service, this could either be provided by the user deploying the MDB or the web service deployer could bind a value to the ENC of the message driven bean as the web service is deployed.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:06:44 2006
From: jira-events at jboss.com (=?UTF-8?Q?Michael_Gr=C3=BCbsch_=28JIRA=29?=)
Date: Thu, 7 Sep 2006 07:06:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-699)
 StackOverflowError in
 org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy
Message-ID: <7825526.1157627204073.JavaMail.jira@cloud.prod.atl2.jboss.com>

StackOverflowError in org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy
-----------------------------------------------------------------------

                 Key: EJBTHREE-699
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-699
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC7 - FD
         Environment: Windows XP
            Reporter: Michael Gr?bsch
            Priority: Critical


I refer to source version $Revision: 1.1.4.2 $

This is an excerpt from the stack trace:

	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
	at $Proxy398.toString(Unknown Source)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)
	at $Proxy398.toString(Unknown Source)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.getProxyString(MessageInflowLocalProxy.java:502)
	at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:114)

You may see, that invoke calls getProxyString which in turn on the proxy calls invoke!



-- 
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

       



From jira-events at jboss.com  Thu Sep  7 07:28:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 07:28:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3631) Missing branch in
 StdServerSession commit logic
Message-ID: <5722134.1157628523903.JavaMail.jira@cloud.prod.atl2.jboss.com>

Missing branch in StdServerSession commit logic
-----------------------------------------------

                 Key: JBAS-3631
                 URL: http://jira.jboss.com/jira/browse/JBAS-3631
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Weston Price
             Fix For: JBossAS-4.0.5.GA


There is a missing branch in the StdServerSession commit logic.

In the case where the transaction manager rollsback the transaction early,
e.g. JBossTM does this for transaction timeouts, the status will be NO_TRANSACTION
(or a heuristic state).

The code:

               // Marked rollback
               if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK)
               {
                  if (trace)
                     log.trace(StdServerSession.this + " rolling back JMS transaction tx=" + trans);
                  // actually roll it back
                  tm.rollback();

                  // NO XASession? then manually rollback.
                  // This is not so good but
                  // it's the best we can do if we have no XASession.
                  if (xaSession == null && serverSessionPool.isTransacted())
                  {
                     session.rollback();
                  }
               }
               else if (trans.getStatus() == Status.STATUS_ACTIVE)
               {
                  // Commit tx
                  // This will happen if
                  // a) everything goes well
                  // b) app. exception was thrown
                  if (trace)
                     log.trace(StdServerSession.this + " commiting the JMS transaction tx=" + trans);
                  tm.commit();

                  // NO XASession? then manually commit.  This is not so good but
                  // it's the best we can do if we have no XASession.
                  if (xaSession == null && serverSessionPool.isTransacted())
                  {
                     session.commit();
                  }
               }

needs an extra branch:

               else
               {
                  if (trace)
                     log.trace(StdServerSession.this + " transaction already ended tx=" + trans);
                  // spend the thread association
                  tm.suspend();

                  // NO XASession? then manually rollback.
                  // This is not so good but
                  // it's the best we can do if we have no XASession.
                  if (xaSession == null && serverSessionPool.isTransacted())
                  {
                     session.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

        


From jira-events at jboss.com  Thu Sep  7 07:28:44 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 07:28:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-464) move to maven for
	build system
In-Reply-To: <27270398.1156948664199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15547257.1157628524036.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-464?page=all ]

Michael Neale resolved JBRULES-464.
-----------------------------------

    Resolution: Done

> move to maven for build system
> ------------------------------
>
>                 Key: JBRULES-464
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-464
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:30:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 07:30:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3632) Too early checking
 of not closing connections
Message-ID: <10803421.1157628643891.JavaMail.jira@cloud.prod.atl2.jboss.com>

Too early checking of not closing connections
---------------------------------------------

                 Key: JBAS-3632
                 URL: http://jira.jboss.com/jira/browse/JBAS-3632
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Weston Price
            Priority: Minor


In the case where a transaction is ended early,
e.g. JBossTM rollsback transactions at a timeout immediately,
the cached connection manager is firing connection not closed events.

This is because the ejb is still in the invocation with the connection open
but the transaction synchronization is fired by the rollback/timeout.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:34:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 07:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-477) BIG REFACTOR:
 rename nodes to
 not have underscores, and pull out jackrabbit deps from the main repository
 class (seperate configuration)
Message-ID: <21151814.1157628883910.JavaMail.jira@cloud.prod.atl2.jboss.com>

BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)
----------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBRULES-477
                 URL: http://jira.jboss.com/jira/browse/JBRULES-477
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: drools-brms
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:34:44 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 07:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-477) BIG REFACTOR:
 rename nodes to
 not have underscores, and pull out jackrabbit deps from the main repository
 class (seperate configuration)
In-Reply-To: <21151814.1157628883910.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14055226.1157628884030.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-477?page=all ]

Michael Neale resolved JBRULES-477.
-----------------------------------

    Resolution: Done

> BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-477
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-477
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:34:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 07:34:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3633) Tidyup logging when
 transaction is no longer active
Message-ID: <12054517.1157628884153.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tidyup logging when transaction is no longer active
---------------------------------------------------

                 Key: JBAS-3633
                 URL: http://jira.jboss.com/jira/browse/JBAS-3633
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JB5-Transaction Manager
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
            Priority: Minor


Since JBossTM rollsback transactions at transaction timeout,
we need to tidyup the transaction demarcation code (commit/rollback/setRollbackOnly, etc)
such that the logging is more information and not so noisy.

We still need to communicate that the transaction rolled back even if it is not
the transaction demarcation point that does the rollback.

Currrently, you get errors/warnings about not being able to setRollbackOnly or rollback,
because the transaction is already ended.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 07:52:44 2006
From: jira-events at jboss.com (cosmin c (JIRA))
Date: Thu, 7 Sep 2006 07:52:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <2293262.1157629964129.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12343008 ] 
            
cosmin c commented on EJBTHREE-402:
-----------------------------------

Hi, I want to do a JUnit Test and I have this problem too ....

avax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.remoting.IsLocalInterceptor;
    local class incompatible: stream classdesc serialVersionUID = -3758782076801249473, local class serialVersionUID = 595045557897063404]
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:722)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
	at javax.naming.InitialContext.lookup(Unknown Source)
	at com.nortel.emp.utils.DeviceProfileManagementTest.getInventory(DeviceProfileManagementTest.java:35)
	at com.nortel.emp.utils.DeviceProfileManagementTest.testLookupInventoryService(DeviceProfileManagementTest.java:52)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

Caused by: java.io.InvalidClassException: org.jboss.ejb3.remoting.IsLocalInterceptor; local class incompatible: 
    stream classdesc serialVersionUID = -3758782076801249473, local class serialVersionUID = 595045557897063404
	at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
	at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
	at java.io.ObjectInputStream.readClassDesc(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.readArray(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
	at java.io.ObjectInputStream.readSerialData(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
	at java.io.ObjectInputStream.readSerialData(Unknown Source)
.......

It seems that I have different version of class org.jboss.ejb3.remoting.IsLocalInterceptor and this is right, but I have a problem when I tried to fix this one. This class apear in my repository in jboss-ejb3-client-4.0.4.jar and in jboss(jboss-ejb3 I have) in jboss-ejb3.jar. Those jars didn't match but if I change only the class IsLocalInterceptor from one to another the test will work, but I can di that, I have to find a better solution. I don't know exactly why I have an older version on jboss server because I have the last version on jboss-ejb3. 

Do you have any ideeas ....

Thanks.



> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 08:38:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 7 Sep 2006 08:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3634) Acknowledgement of
 transacted message in MessageListener should be inside delivery lock
Message-ID: <4660406.1157632723860.JavaMail.jira@cloud.prod.atl2.jboss.com>

Acknowledgement of transacted message in MessageListener should be inside delivery lock
---------------------------------------------------------------------------------------

                 Key: JBAS-3634
                 URL: http://jira.jboss.com/jira/browse/JBAS-3634
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Adrian Brock
             Fix For: JBossAS-4.0.5.GA


The acknowledgement of a transacted message for a MessageListener
should be inside the delivery lock.

Otherwise the addition of the acknowledgement could be competing with other
operations on the session, e.g. commit/rollback/recover.

org.jboss.mq.SpyMessageConsumer::run()

+            // Try to obtain the session delivery lock
+           // This avoids concurrent delivery to message listeners in the same session as per spec
+            boolean gotDeliveryLock = false;
+            while (gotDeliveryLock == false)
+            {

            if (session.transacted)
            {
               // REVIEW: for an XASession without a transaction this will ack the message
               // before it has been processed. Plain message listeners
               // are not supported in a j2ee environment, but what if somebody is trying 
               // to be clever?
               if (trace)
                  log.trace("run() acknowledging message in tx mes=" + mes.getJMSMessageID() + " " + this); 
               session.connection.spyXAResourceManager.ackMessage(session.getCurrentTransactionId(), mes);
            }

-            // Try to obtain the session delivery lock
-            // This avoids concurrent delivery to message listeners in the same session as per spec
-            boolean gotDeliveryLock = false;
-            while (gotDeliveryLock == false)
-            {

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 08:52:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 08:52:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-301) Group partition
 when processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31958230.1157633563955.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-301?page=comments#action_12343013 ] 
            
Bela Ban commented on JGRP-301:
-------------------------------

Works for me, even startup of all 4 processes at the same time. I made 2 changes though:
- Added bind_addr="192.168.5.2" to TCP
- Changed initial_hosts="192.168.5.2[8000]" in TCPPING
- Reduced port_range in TCPPING to 2

I assume 'localhost' is not set to the right IP address in your config

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 08:52:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 08:52:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-301) Group partition when
 processes start almost same time
In-Reply-To: <792233.1157616810677.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15505621.1157633564119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-301?page=all ]

Bela Ban resolved JGRP-301.
---------------------------

    Resolution: Cannot Reproduce Bug

> Group partition when processes start almost same time
> -----------------------------------------------------
>
>                 Key: JGRP-301
>                 URL: http://jira.jboss.com/jira/browse/JGRP-301
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.4
>         Environment: Window XP
>            Reporter: Sammi Ting
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> There are 4 processes named A, B, C, D which should be join in a same group
> Startup Sequence: A->B->C-D
> Scenario:
> 1. Start up A, with 0.5-1 sec time later, immediately start B, C, D
> 2. A join group with itself only (from log file on A, never see B, C, D)
> 3. B, C, D joined group together (from log files on B, C, D, never can see A)
> 4. Wait for long time A still in a single group

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:32:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:32:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-337) language support
 for 'accumulate'
Message-ID: <9684539.1157635964113.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-337?page=all ]

Edson Tirelli reassigned JBRULES-337:
-------------------------------------

    Assignee: Edson Tirelli  (was: Michael Neale)

> language support for 'accumulate'
> ---------------------------------
>
>                 Key: JBRULES-337
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-337
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:32:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:32:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-217) Add 'accumulate'
 Conditional Element
Message-ID: <3528281.1157635964355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-217?page=all ]

Edson Tirelli reassigned JBRULES-217:
-------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)

> Add 'accumulate' Conditional Element
> ------------------------------------
>
>                 Key: JBRULES-217
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-217
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>
> Add jess style accumulate functionality.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:48:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:48:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-336) core reteoo
 implementation for 'accumulate'
Message-ID: <533314.1157636924014.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-336?page=comments#action_12343016 ] 
            
Edson Tirelli commented on JBRULES-336:
---------------------------------------

Commited first version of running code into trunk in revision #6107:

----------------
* JBRULES-217: Adding Accumulate Conditional Element

  * JBRULES-336: Adding core support for Accumulate
    - Implemented AccumulateNode, Accumulate CE, Accumulator interface
    - Added support into ReteooBuilder
    - Added wiring support for generated code

  * JBRULES-337: Adding language support for Accumulate
    - Added grammar rules
    - Added parser support
    - Added AST classes
    - Added rule builder support
    - Added string templates for code generation

  * Added test cases for all classes

----------------
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParser.java
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParserLexer.java
Adding         drools-compiler/src/main/java/org/drools/lang/descr/AccumulateDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/ColumnDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/DescrFactory.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/FunctionBuilder.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/lang/drl.g
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/lang/RuleParserTest.java
Adding         drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate_with_bindings.drl
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrs
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrsPerson
Sending        drools-compiler/src/test/resources/org/drools/reteoo/ThreeColumnsWithConstraints
Sending        drools-core/src/main/java/org/drools/base/dataproviders/MethodDataProvider.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Deleting       drools-core/src/main/java/org/drools/reteoo/Accumulator.java
Deleting       drools-core/src/main/java/org/drools/reteoo/CalculatedObjectHandle.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteooBuilder.java
Adding         drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/rule/PackageCompilationData.java
Sending        drools-core/src/main/java/org/drools/rule/Rule.java
Adding         drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Replacing      drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data ..............................
Committed revision 6107.
------------------

Now, need to improve test scenarios and fix any eventual bug.


> core reteoo implementation for 'accumulate'
> -------------------------------------------
>
>                 Key: JBRULES-336
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-336
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 09:48:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 09:48:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-337) language support
 for 'accumulate'
Message-ID: <23165644.1157636924166.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-337?page=comments#action_12343017 ] 
            
Edson Tirelli commented on JBRULES-337:
---------------------------------------

Commited first version of running code into trunk in revision #6107:

----------------
* JBRULES-217: Adding Accumulate Conditional Element

  * JBRULES-336: Adding core support for Accumulate
    - Implemented AccumulateNode, Accumulate CE, Accumulator interface
    - Added support into ReteooBuilder
    - Added wiring support for generated code

  * JBRULES-337: Adding language support for Accumulate
    - Added grammar rules
    - Added parser support
    - Added AST classes
    - Added rule builder support
    - Added string templates for code generation

  * Added test cases for all classes

----------------
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParser.java
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParserLexer.java
Adding         drools-compiler/src/main/java/org/drools/lang/descr/AccumulateDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/ColumnDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/DescrFactory.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/FunctionBuilder.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/lang/drl.g
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/lang/RuleParserTest.java
Adding         drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/accumulate_with_bindings.drl
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrs
Sending        drools-compiler/src/test/resources/org/drools/reteoo/OneAndTwoOrsPerson
Sending        drools-compiler/src/test/resources/org/drools/reteoo/ThreeColumnsWithConstraints
Sending        drools-core/src/main/java/org/drools/base/dataproviders/MethodDataProvider.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Deleting       drools-core/src/main/java/org/drools/reteoo/Accumulator.java
Deleting       drools-core/src/main/java/org/drools/reteoo/CalculatedObjectHandle.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteooBuilder.java
Adding         drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/rule/PackageCompilationData.java
Sending        drools-core/src/main/java/org/drools/rule/Rule.java
Adding         drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Replacing      drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data ..............................
Committed revision 6107.
------------------

Now, need to improve test scenarios and fix any eventual bug.


> language support for 'accumulate'
> ---------------------------------
>
>                 Key: JBRULES-337
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-337
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:06:46 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 7 Sep 2006 10:06:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-619) PojoCache to
 support JDK5.0 Enum
Message-ID: <27958706.1157638006529.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-619?page=comments#action_12343019 ] 
            
Ben Wang commented on JBCACHE-619:
----------------------------------

No, ejb3 entity cache doesn't use PojoCache. It uses the regular TreeCache, rather. So it should not be an issue there.

> PojoCache to support JDK5.0 Enum
> --------------------------------
>
>                 Key: JBCACHE-619
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-619
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>
> In JDK5.0, Enum is Serializabe. We need to look into whether it is possible to intercept Enum operation as well.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:27:28 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 10:27:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-478) eclipse plugin
 support for 'accumulate'
Message-ID: <10605990.1157639248991.JavaMail.jira@cloud.prod.atl2.jboss.com>

eclipse plugin support for 'accumulate'
---------------------------------------

                 Key: JBRULES-478
                 URL: http://jira.jboss.com/jira/browse/JBRULES-478
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Kris Verlaenen




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:31:31 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Thu, 7 Sep 2006 10:31:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-478) eclipse plugin
 support for 'accumulate'
In-Reply-To: <10605990.1157639248991.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27735354.1157639491531.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-478?page=all ]

Edson Tirelli updated JBRULES-478:
----------------------------------

      Component/s: Eclipse IDE
    Fix Version/s: 3.1-m1
      Description: 
Kris, 

We need to add support to 'accumulate' in the Eclipse plugin. I'm still testing the more complex functionality, but the basics are there (commited to trunk in revision #6107), so I guess you are free to work your side when you have the time. 

There is an integration test you can use: test_Accumulate.drl.

Let me know if you have any question. 

Thanks,
Edson

> eclipse plugin support for 'accumulate'
> ---------------------------------------
>
>                 Key: JBRULES-478
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-478
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Edson Tirelli
>         Assigned To: Kris Verlaenen
>             Fix For: 3.1-m1
>
>
> Kris, 
> We need to add support to 'accumulate' in the Eclipse plugin. I'm still testing the more complex functionality, but the basics are there (commited to trunk in revision #6107), so I guess you are free to work your side when you have the time. 
> There is an integration test you can use: test_Accumulate.drl.
> Let me know if you have any question. 
> Thanks,
> Edson

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:41:31 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Thu, 7 Sep 2006 10:41:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-479) Wizard for
 autopopulating a decision table
Message-ID: <667045.1157640091287.JavaMail.jira@cloud.prod.atl2.jboss.com>

Wizard for autopopulating a decision table
------------------------------------------

                 Key: JBRULES-479
                 URL: http://jira.jboss.com/jira/browse/JBRULES-479
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Michael Neale
         Assigned To: Mark Proctor
            Priority: Minor


This could be done quite easily by a contributor.

Have a wizard (in the IDE) which takes information regarding the facts to be used, fields, actions (and the number of each) and generates a decision table based on that info capture (ie populates it).

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 10:43:33 2006
From: jira-events at jboss.com (Sam Healy (JIRA))
Date: Thu, 7 Sep 2006 10:43:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-747) Add configuration
 type of "normal"
 or "default" to the gpd action handler configuration dialog
Message-ID: <12536108.1157640213142.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add configuration type of "normal" or "default" to the gpd action handler configuration dialog
----------------------------------------------------------------------------------------------

                 Key: JBPM-747
                 URL: http://jira.jboss.com/jira/browse/JBPM-747
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Graphical Process Designer
    Affects Versions:  jBPM 3.1.2
         Environment: Win XP Pro, Eclipse 3.1.2
            Reporter: Sam Healy
         Assigned To: Tom Baeyens


When configuring action handlers on nodes using the gpd, no option is provided in the configuration window to use a configuration type of "default" or "normal" where a simple instantiation of the action class would suffice. As it is now, the implication is that an action class of this nature cannot be used. 

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 11:20:31 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Thu, 7 Sep 2006 11:20:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-362) NPE from
 org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
Message-ID: <24905392.1157642431741.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE from org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
-----------------------------------------------------------------------------------

                 Key: JBIDE-362
                 URL: http://jira.jboss.com/jira/browse/JBIDE-362
             Project: JBoss IDE
          Issue Type: Bug
          Components: JBossAS Adapter
    Affects Versions: 2.0.0.Beta1
            Reporter: Darryl Miles
         Assigned To: Robert Stryker


Just thought I'd report this.

java.lang.NullPointerException
at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports(ArchiveModuleFactory.java:64)
at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.acceptAddition(ArchiveModuleFactory.java:33)
at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory$1.visit(JBossModuleFactory.java:88)
at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:105)
at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:103)
at org.eclipse.core.internal.resources.Resource.accept(Resource.java:87)
at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.cacheModules(JBossModuleFactory.java:86)
at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.getModules(JBossModuleFactory.java:66)
at org.eclipse.wst.server.core.internal.ModuleFactory.getModules(ModuleFactory.java:133)
at org.eclipse.wst.server.core.ServerUtil.getModules(ServerUtil.java:285)
at org.eclipse.wst.server.core.ServerUtil.getModule(ServerUtil.java:52)
at org.eclipse.wst.web.internal.deployables.ComponentDeployable.gatherModuleReference(ComponentDeployable.java:126)
at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.gatherModuleReference(J2EEFlexProjDeployable.java:466)
at org.eclipse.wst.web.internal.deployables.ComponentDeployable.getModules(ComponentDeployable.java:113)
at org.eclipse.jst.server.tomcat.core.internal.TomcatServer.getChildModules(TomcatServer.java:212)
at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2174)
at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:2334)
at org.eclipse.wst.server.core.internal.Server.visit(Server.java:2315)
at org.eclipse.wst.server.core.internal.Server.shouldRestart(Server.java:805)
at org.eclipse.wst.server.ui.internal.view.servers.ServerTableLabelProvider.getColumnText(ServerTableLabelProvider.java:183)
at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:309)
at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:95)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:843)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:849)
at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:465)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.runtime.Platform.run(Platform.java:843)
at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1955)
at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:753)
at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
at org.eclipse.wst.server.ui.internal.view.servers.ServerTableViewer.<init>(ServerTableViewer.java:240)
at org.eclipse.wst.server.ui.internal.view.servers.ServersView.createPartControl(ServersView.java:89)
at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:290)
at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:525)
at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:140)
at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268)
at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:394)
at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1144)
at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:620)
at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:532)
at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:562)
at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:244)
at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:815)
at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3284)
at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:957)
at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:941)
at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3408)
at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3406)
at org.eclipse.ui.internal.PerspectiveBarContributionItem.select(PerspectiveBarContributionItem.java:123)
at org.eclipse.ui.internal.PerspectiveBarContributionItem$1.widgetSelected(PerspectiveBarContributionItem.java:92)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3166)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2842)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
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:336)
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)


-- 
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

        


From jira-events at jboss.com  Thu Sep  7 11:22:44 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Thu, 7 Sep 2006 11:22:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-362) NPE from
 org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
In-Reply-To: <24905392.1157642431741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3711645.1157642564561.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-362?page=comments#action_12343023 ] 
            
Darryl Miles commented on JBIDE-362:
------------------------------------

Hmm... the version of the plugin code is this:

eclipse/plugins/org.jboss.ide.eclipse.as.core_1.0.0.Beta1/jbossascore.jar

Even thought I put 2.0.0.Beta1.

> NPE from org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
> -----------------------------------------------------------------------------------
>
>                 Key: JBIDE-362
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-362
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Robert Stryker
>
> Just thought I'd report this.
> java.lang.NullPointerException
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports(ArchiveModuleFactory.java:64)
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.acceptAddition(ArchiveModuleFactory.java:33)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory$1.visit(JBossModuleFactory.java:88)
> at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:105)
> at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
> at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:103)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:87)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.cacheModules(JBossModuleFactory.java:86)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.getModules(JBossModuleFactory.java:66)
> at org.eclipse.wst.server.core.internal.ModuleFactory.getModules(ModuleFactory.java:133)
> at org.eclipse.wst.server.core.ServerUtil.getModules(ServerUtil.java:285)
> at org.eclipse.wst.server.core.ServerUtil.getModule(ServerUtil.java:52)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.gatherModuleReference(ComponentDeployable.java:126)
> at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.gatherModuleReference(J2EEFlexProjDeployable.java:466)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.getModules(ComponentDeployable.java:113)
> at org.eclipse.jst.server.tomcat.core.internal.TomcatServer.getChildModules(TomcatServer.java:212)
> at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2174)
> at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:2334)
> at org.eclipse.wst.server.core.internal.Server.visit(Server.java:2315)
> at org.eclipse.wst.server.core.internal.Server.shouldRestart(Server.java:805)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableLabelProvider.getColumnText(ServerTableLabelProvider.java:183)
> at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:309)
> at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:95)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:849)
> at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:465)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1955)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:753)
> at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
> at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
> at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
> at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
> at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
> at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
> at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableViewer.<init>(ServerTableViewer.java:240)
> at org.eclipse.wst.server.ui.internal.view.servers.ServersView.createPartControl(ServersView.java:89)
> at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
> at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
> at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
> at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:290)
> at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:525)
> at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:140)
> at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268)
> at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
> at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:394)
> at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1144)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:620)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:532)
> at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:562)
> at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:244)
> at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:815)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3284)
> at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:957)
> at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:941)
> at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3408)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3406)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem.select(PerspectiveBarContributionItem.java:123)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem$1.widgetSelected(PerspectiveBarContributionItem.java:92)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3166)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2842)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
> 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:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:07:44 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 7 Sep 2006 12:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-760)
 TreeCacheListener in
 PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27865978.1157645264317.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=comments#action_12343027 ] 
            
Ben Wang commented on JBCACHE-760:
----------------------------------

Can you verify that this is also a problem with regular pojo? I'd think getObject in nodeModify will run into the same problem.

On a separate node, I am switching to pojo-based event listening. So this will not be a problem anymore in 2.0 release.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:09:43 2006
From: jira-events at jboss.com (Manfred Moser (JIRA))
Date: Thu, 7 Sep 2006 12:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8451088.1157645383709.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=comments#action_12343028 ] 
            
Manfred Moser commented on JBSEAM-340:
--------------------------------------

It is great that specifiying the resource bundle actually works however it is a bit counter intuitive when developing. You have to have it in the EJBs but you dont have to have it in other seam components. This should maybe be streamlined. At least there should be an example in the actual distro. And yes .. I agree that the hibnerate like variables should work too. In fact my entity unit tests test the validation with the hibernate validator assuming it would work in Seam. 



> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Thu Sep  7 12:15:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Thu, 7 Sep 2006 12:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1967635.1157645743816.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Nitzan Niv updated JBCACHE-760:
-------------------------------

    Attachment: TreeCacheAopListenerTest.java

tests for events on a PojoCache

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:17:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Thu, 7 Sep 2006 12:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-760)
 TreeCacheListener in
 PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11799140.1157645863838.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=comments#action_12343030 ] 
            
Nitzan Niv commented on JBCACHE-760:
------------------------------------

It does not happen on a non-collection object, only on collections. See attached tests.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:26:30 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Thu, 7 Sep 2006 12:26:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-289) Make service
 container configurable wrt datasource and persistence manager config
Message-ID: <19049348.1157646390609.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-289?page=comments#action_12343032 ] 
            
Tim Fox commented on JBMESSAGING-289:
-------------------------------------

We also need to make sure that when creating a PostOffice or any other component that requires sqlProperties the correct properties, in a core test, the correct properties are configured.
Currently this is not the case.

> Make service container configurable wrt datasource and persistence manager config
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-289
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-289
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>
> Must be made configurable so test suite can be run against different databases with different pm configs

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:36:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 12:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1024) Verify theme CSS
 compatible with multiple browsers/OS
Message-ID: <12922402.1157647004240.JavaMail.jira@cloud.prod.atl2.jboss.com>

Verify theme CSS compatible with multiple browsers/OS
-----------------------------------------------------

                 Key: JBPORTAL-1024
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1024
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 12:36:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 12:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1025) Integrate new
 theme with portal codebase
Message-ID: <22595979.1157647004438.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate new theme with portal codebase
----------------------------------------

                 Key: JBPORTAL-1025
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1025
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 13:35:44 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 7 Sep 2006 13:35:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-700) add ability to add
 descriptions to jmx operations in Service beans
Message-ID: <916539.1157650544830.JavaMail.jira@cloud.prod.atl2.jboss.com>

add ability to add descriptions to jmx operations in Service beans
------------------------------------------------------------------

                 Key: EJBTHREE-700
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-700
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC8 - FD
            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

        


From jira-events at jboss.com  Thu Sep  7 14:08:40 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 7 Sep 2006 14:08:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-300) NAKACK.send()
 doesn't need to be synchronized
In-Reply-To: <9351729.1157614648499.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <720114.1157652520054.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-300?page=all ]

Bela Ban resolved JGRP-300.
---------------------------

    Resolution: Done

> NAKACK.send() doesn't need to be synchronized
> ---------------------------------------------
>
>                 Key: JGRP-300
>                 URL: http://jira.jboss.com/jira/browse/JGRP-300
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> NAKACK.send() currently calls passDown(evt) in a synchronized(sent_msgs) statement. However, this is not necessary (contrary to handleMessage() which needs to pass messages up in the order of sequence numbers) because messages can be sent un-ordered. The receivers will order the messages anyway, so if we sent 1,3,2,4 due to thread premption, the receivers will order them and deliver them as 1,2,3,4.
> BENEFIT: the less synchronization, the less probability of deadlocks

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:01:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 15:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1026) Fix Tabs CSS to
 work with existing Navigation CSS
Message-ID: <9596533.1157655703858.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix Tabs CSS to work with existing Navigation CSS
-------------------------------------------------

                 Key: JBPORTAL-1026
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1026
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:01:43 2006
From: jira-events at jboss.com (Ole Matzura (JIRA))
Date: Thu, 7 Sep 2006 15:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-350) create
 specification for jbossws/jbosside plugin / integration
In-Reply-To: <30880297.1155172032601.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23282358.1157655703989.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-350?page=comments#action_12343043 ] 
            
Ole Matzura commented on JBIDE-350:
-----------------------------------

I agree.. there seems to be an infrastructure for this (see http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.wst.doc.isv/html/plugin_descriptions_WST/ws.html), but I cant find much documentation.. I'll download the WTP sources and have a look.. ;-)



> create specification for jbossws/jbosside plugin / integration
> --------------------------------------------------------------
>
>                 Key: JBIDE-350
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-350
>             Project: JBoss IDE
>          Issue Type: Task
>          Components: Webservices Plugin
>            Reporter: Ole Matzura
>         Assigned To: Ole Matzura
>             Fix For: 2.0.0.Beta2
>
>         Attachments: JBossWS Eclipse Plugin Specification.doc
>
>
> we need a spec that outlines how jbossws should be integrated into eclipse/jbosside

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:07:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 15:07:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1027) New Renderer for
	New UI
Message-ID: <24226605.1157656063859.JavaMail.jira@cloud.prod.atl2.jboss.com>

New Renderer for New UI
-----------------------

                 Key: JBPORTAL-1027
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1027
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


Develop new Renderer class for new layout/theme.

The new usability requires additional functionality, that requires a new renderer:
1. New icon placement: ie, the remove window icon.
2. New region for Adding Content to a page.

Issues: New renderer will not be compatible with previous themes/layouts.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:11:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 7 Sep 2006 15:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1028) Modify
 navigationportlet for scope-colored tabbing
Message-ID: <16685103.1157656303867.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify navigationportlet for scope-colored tabbing
--------------------------------------------------

                 Key: JBPORTAL-1028
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1028
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 15:19:43 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 7 Sep 2006 15:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-701) different
 interceptor stack
 for same method based on call via remote or local interface
Message-ID: <9781897.1157656783817.JavaMail.jira@cloud.prod.atl2.jboss.com>

different interceptor stack for same method based on call via remote or local interface
---------------------------------------------------------------------------------------

                 Key: EJBTHREE-701
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-701
             Project: EJB 3.0
          Issue Type: Feature Request
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: William DeCoste
         Assigned To: William DeCoste
            Priority: Optional




-- 
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

        


From jira-events at jboss.com  Thu Sep  7 19:55:26 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 19:55:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-327) Relax required=true
 in @Create and @Destroy methods
In-Reply-To: <10704879.1154964012187.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <77824.1157673326949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-327?page=all ]

Gavin King updated JBSEAM-327:
------------------------------

    Comment: was deleted

> Relax required=true in @Create and @Destroy methods
> ---------------------------------------------------
>
>                 Key: JBSEAM-327
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-327
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Might be convenient to relax required=true during lifecycle callbacks (but don't forget the EJB3 callbacks @PostCostruct/@PreDestroy/@PrePassivate/@PostActivate)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 19:57:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 19:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-338) Changes to
 SeamInterceptor break non-JSF calls.
In-Reply-To: <8417461.1156344946502.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13576981.1157673447143.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-338?page=comments#action_12343048 ] 
            
Gavin King commented on JBSEAM-338:
-----------------------------------

Note that this also occurs for finalizers.

> Changes to SeamInterceptor break non-JSF calls.
> -----------------------------------------------
>
>                 Key: JBSEAM-338
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-338
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>
> The CVS changes to SeamInterceptor have it call Component.forName() outside of the Seam contexts when called via MDB or RMI. Need to call beginCall(), endCall() from the @PostConstruct and @PostActivate methods.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:15:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:15:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-327) Relax required=true
 in @Create and @Destroy methods
In-Reply-To: <10704879.1154964012187.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9388449.1157674527330.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-327?page=all ]

Gavin King closed JBSEAM-327.
-----------------------------

    Resolution: Done

done

> Relax required=true in @Create and @Destroy methods
> ---------------------------------------------------
>
>                 Key: JBSEAM-327
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-327
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Might be convenient to relax required=true during lifecycle callbacks (but don't forget the EJB3 callbacks @PostCostruct/@PreDestroy/@PrePassivate/@PostActivate)

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:17:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:17:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-338) Changes to
 SeamInterceptor break non-JSF calls.
In-Reply-To: <8417461.1156344946502.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11099714.1157674647478.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-338?page=all ]

Gavin King updated JBSEAM-338:
------------------------------

    Comment: was deleted

> Changes to SeamInterceptor break non-JSF calls.
> -----------------------------------------------
>
>                 Key: JBSEAM-338
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-338
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>
> The CVS changes to SeamInterceptor have it call Component.forName() outside of the Seam contexts when called via MDB or RMI. Need to call beginCall(), endCall() from the @PostConstruct and @PostActivate methods.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:19:29 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:19:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17320746.1157674769148.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=all ]

Gavin King closed JBSEAM-342.
-----------------------------

    Resolution: Won't Fix

We do not support nonstandard features of MyFaces.

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:21:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-344) Portal booking
 example loses conversation after validation error
In-Reply-To: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6515142.1157674887476.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-344?page=comments#action_12343051 ] 
            
Gavin King commented on JBSEAM-344:
-----------------------------------

This is probably due to a (fixed) known bug in that version of JBoss Portal where render parameters were "lost" by the portal.

> Portal booking example loses conversation after validation error
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-344
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Portal
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4.GA
> JBoss Portal 2.4.0-Beta1
> (used jems-installer-1.2.0.BETA)
> JBoss Seam 1.0.1.GA
>            Reporter: Mauro Lopez
>
> Followed this steps:
> - deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
> - Entered http://localhost:8080/portal
> - Selected the SeamHibernate portlet tab, registered user, logged in...
> - Searched hotels, selected one of them, and pressed the "Book" button.
> In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 
> So, after a failed validation, the conversation is lost.
> In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:21:27 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:21:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-346) Full <ejb-jar>
 declaration in examples' ejb-jar.xml files
In-Reply-To: <27019148.1157613568758.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3335927.1157674887861.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-346?page=all ]

Gavin King closed JBSEAM-346.
-----------------------------

    Resolution: Duplicate Issue

dupe

> Full <ejb-jar> declaration in examples' ejb-jar.xml files
> ---------------------------------------------------------
>
>                 Key: JBSEAM-346
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-346
>             Project: JBoss Seam
>          Issue Type: Task
>          Components: Examples
>    Affects Versions: 1.0.1
>            Reporter: Stephen Friedrich
>
> Currently ejb-jar.xml files in seam examples (1.0.1 GA) use just "<ejb-jar>".
> Would be nicer if they used a full, standard compliant declaration:
> {code}
> <ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
>          version="3.0">	
> {code}

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:23:28 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:23:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-336) BigDecimal is not
 handled properly
In-Reply-To: <31483451.1155912041653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3479140.1157675008777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-336?page=all ]

Gavin King closed JBSEAM-336.
-----------------------------

    Resolution: Won't Fix

Not an issue in Seam. Hibernate Tools, if anything.

> BigDecimal is not handled properly
> ----------------------------------
>
>                 Key: JBSEAM-336
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-336
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: German or US locale, Windows XP Pro, myfaces 1.1.3, Oracle 9.2 or MySQL 4.1.9 
>            Reporter: Valerij Timofeev
>
> Generating CRUD Seam applications results in some fields having Java type BigDecimal.
> It seems that this type is not handled properly.
> There are no error messages in the JBoss server.log (log4j javax.faces & org.jboss.seam priorities are DEBUG). Query returns no results.
> Debugging shows for example that findFirstPage() method is never called.
> Changing type e.g. to Double fixes the issue (see workarounds for details) : it becomes possible to step through the method. And query returns some results.
> Clicking on create link and then switching to find view (other bean than current) results in the following JSF error:
> Cannot set value for expression '#{somebeanEditor.instance.id}' to a new value of type java.lang.String
> Where ID is of type BigDecimal.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 20:27:26 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 7 Sep 2006 20:27:26 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2221777.1157675246297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=all ]

Gavin King reassigned JBSEAM-340:
---------------------------------

    Assignee: Emmanuel Bernard

> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>         Assigned To: Emmanuel Bernard
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Thu Sep  7 22:03:27 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Thu, 7 Sep 2006 22:03:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12286997.1157681007691.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12343055 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

Nice support guys thanks.

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 22:03:27 2006
From: jira-events at jboss.com (Sergei Rogovskiy (JIRA))
Date: Thu, 7 Sep 2006 22:03:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-342) CLONE -Seam and
 Myfaces ajax support.
In-Reply-To: <33192667.1157433326401.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3139706.1157681007828.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-342?page=comments#action_12343056 ] 
            
Sergei Rogovskiy commented on JBSEAM-342:
-----------------------------------------

You just need to support JSF spec well.

> CLONE -Seam and Myfaces ajax support.
> -------------------------------------
>
>                 Key: JBSEAM-342
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-342
>             Project: JBoss Seam
>          Issue Type: Feature Request
>         Environment: Jboss 4.0.4 + Seam beta + SVN myfaces
>            Reporter: Sergei Rogovskiy
>
> Hi,
> I have tried to use seam and myfaces sandbox component InputSugestAjax.
>  Is hapen some strage problem in variable resolver, or method rezolver for ajax requests.. 
> Please verify this issue, Maibe in the feature will be a problem in integration.
> Thanks,
> Cristi

-- 
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

        


From c10 at fullmailmarket.com  Thu Sep  7 23:31:20 2006
From: c10 at fullmailmarket.com (Facultad Economía y Negocio U. de Chile)
Date: Thu, 7 Sep 2006 23:31:20 -0400
Subject: [jboss-jira] =?iso-8859-1?q?Diplomado_Gesti=F3n_Integrada_-_La_S?=
	=?iso-8859-1?q?erena?=
Message-ID: <200609080331.k883VKgH026687@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060907/9a4b2ced/attachment-0001.html 

From jira-events at jboss.com  Thu Sep  7 23:38:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 7 Sep 2006 23:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-424) Cannot access
 the first message when starting the JMS subscriber
Message-ID: <18420198.1157686723975.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-424?page=all ]

Clebert Suconic closed JBMESSAGING-424.
---------------------------------------

    Resolution: Duplicate Issue

This issue was fixed as a duplicate.

However I double checked this by creating another testcase

> Cannot access the first message when starting the JMS subscriber
> ----------------------------------------------------------------
>
>                 Key: JBMESSAGING-424
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-424
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: JBoss jboss-4.0.4.GA & jboss-messaging-1.0.1.CR2 
>            Reporter: Seung Hyun
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>
> Some messages are already published to the specific queue and the queue contains few messages. Starts the subscriber to receive the messages in the queue. It reads all the messages except the first message. Also, the first message is not accessible at all.

-- 
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

        


From jira-events at jboss.com  Thu Sep  7 23:40:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 7 Sep 2006 23:40:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
Message-ID: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>

Crash Test failure on Durable Subscriber
----------------------------------------

                 Key: JBMESSAGING-541
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.0.1.CR5, 1.2.0.Alpha1


DurableSubscriberCrashTest1 and 2 are failing.
The routine that verifies if a connection is broken is only called upon communication exceptions. 

If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 04:55:31 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 04:55:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-348) IssueTracker
 example uses nonexisting annotation (Within)
Message-ID: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>

IssueTracker example uses nonexisting annotation (Within)
---------------------------------------------------------

                 Key: JBSEAM-348
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
             Project: JBoss Seam
          Issue Type: Bug
          Components: Examples
            Reporter: Stephan Bublava
            Priority: Trivial


org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Fri Sep  8 04:57:33 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 04:57:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-349) IssueTracker
 @LoggedIn missing @Interceptors annotation
Message-ID: <931519.1157705853664.JavaMail.jira@cloud.prod.atl2.jboss.com>

IssueTracker @LoggedIn missing @Interceptors annotation
-------------------------------------------------------

                 Key: JBSEAM-349
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-349
             Project: JBoss Seam
          Issue Type: Bug
          Components: Examples
            Reporter: Stephan Bublava
            Priority: Trivial


I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 05:03:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 8 Sep 2006 05:03:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-748) check variable
 hibernatability before serializability
Message-ID: <10629469.1157706212979.JavaMail.jira@cloud.prod.atl2.jboss.com>

check variable hibernatability before serializability
-----------------------------------------------------

                 Key: JBPM-748
                 URL: http://jira.jboss.com/jira/browse/JBPM-748
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1


when a variable is persisted, the order in which serializability and hibernatability is checked should be reversed.    the new behaviour should be that first hibernatability is checked and only afterwards, serializability should be checked.

see also: http://blogs.sourceallies.com/roller/page/joedeveloper?entry=jbpm_3_1_auto_user

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 05:07:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 8 Sep 2006 05:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-748) check variable
 hibernatability before serializability
In-Reply-To: <10629469.1157706212979.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1495723.1157706452319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-748?page=all ]

Tom Baeyens closed JBPM-748.
----------------------------

    Resolution: Done

> check variable hibernatability before serializability
> -----------------------------------------------------
>
>                 Key: JBPM-748
>                 URL: http://jira.jboss.com/jira/browse/JBPM-748
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1
>
>
> when a variable is persisted, the order in which serializability and hibernatability is checked should be reversed.    the new behaviour should be that first hibernatability is checked and only afterwards, serializability should be checked.
> see also: http://blogs.sourceallies.com/roller/page/joedeveloper?entry=jbpm_3_1_auto_user

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:17:30 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:17:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-363) Switch mode dialog
 asks for
 restart server if necessary, but restarts the server innecessary even when
 server is already in Debug mode
Message-ID: <21059668.1157721450807.JavaMail.jira@cloud.prod.atl2.jboss.com>

Switch mode dialog asks for restart server if necessary, but restarts the server innecessary even when server is already in Debug mode
--------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBIDE-363
                 URL: http://jira.jboss.com/jira/browse/JBIDE-363
             Project: JBoss IDE
          Issue Type: Bug
    Affects Versions: 2.0.0.Beta1
         Environment: Windows 2003 Server
jdk1.5.0_06
JBoss-4.0.4.GA
eclipse-M20060823

            Reporter: Johans Marvin Taboada Villca


When deploying (new) module (Degug as -> Debug On Server), wizard show information dialog asking to switch 
mode. Apparently isn't aware that server is already in debug mode. In any case it suggest 'Switch mode (will 
restart if necessary)', but this always restarts the server. One can avoid this bug by choosing 'Continue in the 
current mode' instead.


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:29:29 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:29:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-364) Secured JBoss server
 configured via 'JBoss Server View' fail to Start/Debug
Message-ID: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>

Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
---------------------------------------------------------------------------

                 Key: JBIDE-364
                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
             Project: JBoss IDE
          Issue Type: Bug
          Components: JBossAS Adapter
    Affects Versions: 2.0.0.Beta1
         Environment: Windows Server 2003
eclipse-M20060823-1200
JBoss-4.0.4.GA
jdk1.5.0_06
MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
jmx-console also secured with the same security Domain.

            Reporter: Johans Marvin Taboada Villca
         Assigned To: Robert Stryker


Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
- MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
   <descriptors>
      <interceptors>
         <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
            securityDomain="java:/jaas/jmx-console"/>
      </interceptors>
   </descriptors>
Im assuming that the 'jmx-console' is also secured with the same security Domain.
Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
on the server.


-- 
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

       



From jira-events at jboss.com  Fri Sep  8 09:43:29 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 8 Sep 2006 09:43:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-466) refactor
 RulesRepository to be injected JCR repository
In-Reply-To: <5779102.1157012983858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15270793.1157723009768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-466?page=all ]

Michael Neale resolved JBRULES-466.
-----------------------------------

    Resolution: Done

> refactor RulesRepository to be injected JCR repository
> ------------------------------------------------------
>
>                 Key: JBRULES-466
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-466
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>
> this is so in a container, it can come from JNDI etc... and test can use transient repository 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

        


From jira-events at jboss.com  Fri Sep  8 09:45:27 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:45:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-364) Secured JBoss
 server configured via 'JBoss Server View' fail to Start/Debug
In-Reply-To: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8709209.1157723127384.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-364?page=comments#action_12343067 ] 
            
Johans Marvin Taboada Villca commented on JBIDE-364:
----------------------------------------------------

>From the JBoss 'Server Editor' there's a link 'Edit' that is supposed to edit Runtime preferences, that's the right place to enter admin credentials for the JBossAdmin role, but its not working (at leats for me). Launch configuration is working fine.

> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-364
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200
> JBoss-4.0.4.GA
> jdk1.5.0_06
> MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
> jmx-console also secured with the same security Domain.
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>
> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
> - MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
> has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
>    <descriptors>
>       <interceptors>
>          <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
>             securityDomain="java:/jaas/jmx-console"/>
>       </interceptors>
>    </descriptors>
> Im assuming that the 'jmx-console' is also secured with the same security Domain.
> Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
> on the server.

-- 
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

       



From jira-events at jboss.com  Fri Sep  8 09:51:29 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 8 Sep 2006 09:51:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-412) Create web app
 component infrastructure
In-Reply-To: <2895546.1155288372585.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25393510.1157723489774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-412?page=all ]

Michael Neale resolved JBRULES-412.
-----------------------------------

    Resolution: Done

> Create web app component infrastructure
> ---------------------------------------
>
>                 Key: JBRULES-412
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-412
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Using Seam, or otherwise, need a "back end" web component framework which will work with the GWT generated UI, and use the drools-repository api.
> This task is just to setup the initial skeleton for development

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:55:29 2006
From: jira-events at jboss.com (Mauro Lopez (JIRA))
Date: Fri, 8 Sep 2006 09:55:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-344) Portal booking
 example loses conversation after validation error
In-Reply-To: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22238454.1157723729689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-344?page=all ]

Mauro Lopez updated JBSEAM-344:
-------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90229

> Portal booking example loses conversation after validation error
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-344
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Portal
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4.GA
> JBoss Portal 2.4.0-Beta1
> (used jems-installer-1.2.0.BETA)
> JBoss Seam 1.0.1.GA
>            Reporter: Mauro Lopez
>
> Followed this steps:
> - deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
> - Entered http://localhost:8080/portal
> - Selected the SeamHibernate portlet tab, registered user, logged in...
> - Searched hotels, selected one of them, and pressed the "Book" button.
> In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 
> So, after a failed validation, the conversation is lost.
> In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 09:57:29 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 09:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-365) Changing hostname in
 server
 config (JBoss 'Server Editor'), breaks twiddle monitoring for server
 startup
Message-ID: <24852255.1157723849263.JavaMail.jira@cloud.prod.atl2.jboss.com>

Changing hostname in server config (JBoss 'Server Editor'), breaks twiddle monitoring for server startup
--------------------------------------------------------------------------------------------------------

                 Key: JBIDE-365
                 URL: http://jira.jboss.com/jira/browse/JBIDE-365
             Project: JBoss IDE
          Issue Type: Bug
          Components: JBossAS Adapter
    Affects Versions: 2.0.0.Beta1
         Environment: Windows Server 2003
eclipse-M20060823-1200 (eclipse 3.2)
JBoss-4.0.4.GA
jdk1.5.0_06
            Reporter: Johans Marvin Taboada Villca
         Assigned To: Robert Stryker


Changing hostname in server config view breaks twiddle monitoring for server startup
Posible cause, maybe JBossIDE (?JBossAS Adapter?) access to twiddle script doesn't use yet
$WORKSPACE\.metadata\.plugins\org.eclipse.wst.server.core\servers.xml
to set -s option on the twiddle script.
Also, changing hostname doesn't change Launch configuration, where argument '--host=localhost' is set by default.
file: $WORKSPACE\.metadata\.plugins\org.eclipse.debug.core\.launches\JBoss-4.0.4.GA.launch


-- 
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

       



From jira-events at jboss.com  Fri Sep  8 10:11:33 2006
From: jira-events at jboss.com (Johans Marvin Taboada Villca (JIRA))
Date: Fri, 8 Sep 2006 10:11:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-366) Renaming Server Name
 (Host name) twice, pops up an error dialog
Message-ID: <3913669.1157724693540.JavaMail.jira@cloud.prod.atl2.jboss.com>

Renaming Server Name (Host name) twice, pops up an error dialog
---------------------------------------------------------------

                 Key: JBIDE-366
                 URL: http://jira.jboss.com/jira/browse/JBIDE-366
             Project: JBoss IDE
          Issue Type: Bug
    Affects Versions: 2.0.0.Beta1
         Environment: Windows Server 2003
eclipse-M20060823-1200 (eclipse 3.2)
JBoss-4.0.4.GA
jdk1.5.0_06

            Reporter: Johans Marvin Taboada Villca


Renaming Server Name (Host name) twice in the JBoss 'Server Editor', pops up an error dialog:
'Error while saving. Could not save because the file has been modified since the start of editting'
Once someone has change it and save it, must close the editor and reopen it, if needs to rename it again.


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 10:53:28 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 8 Sep 2006 10:53:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBRULES-477) BIG REFACTOR:
 rename nodes to
 not have underscores, and pull out jackrabbit deps from the main repository
 class (seperate configuration)
In-Reply-To: <21151814.1157628883910.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14276114.1157727208852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-477?page=all ]

Michael Neale closed JBRULES-477.
---------------------------------


> BIG REFACTOR: rename nodes to not have underscores, and pull out jackrabbit deps from the main repository class (seperate configuration)
> ----------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-477
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-477
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 10:57:30 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Fri, 8 Sep 2006 10:57:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-107) Find an actual
 machine and load up the new forums here
In-Reply-To: <8992194.1153928592068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7911307.1157727450316.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-107?page=all ]

Sohil Shah resolved JBFORUMS-107.
---------------------------------

    Resolution: Done

These are hosted on http://forums.proto.jboss.com:8080/portal

> Find an actual machine and load up the new forums here
> ------------------------------------------------------
>
>                 Key: JBFORUMS-107
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-107
>             Project: JBoss Forums
>          Issue Type: Sub-task
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 1 day
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:03:43 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 11:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-348) IssueTracker
 example uses nonexisting annotation (Within)
In-Reply-To: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13966331.1157727823758.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-348?page=all ]

Stephan Bublava updated JBSEAM-348:
-----------------------------------


This refers to the latest version available via anoncvs.forge.jboss.com (as of this morning).

> IssueTracker example uses nonexisting annotation (Within)
> ---------------------------------------------------------
>
>                 Key: JBSEAM-348
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>
> org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Fri Sep  8 11:05:43 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Fri, 8 Sep 2006 11:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-349) IssueTracker
 @LoggedIn missing @Interceptors annotation
In-Reply-To: <931519.1157705853664.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28874205.1157727943790.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-349?page=all ]

Stephan Bublava updated JBSEAM-349:
-----------------------------------


This refers to the latest version available via anoncvs.forge.jboss.com (as of this morning).

> IssueTracker @LoggedIn missing @Interceptors annotation
> -------------------------------------------------------
>
>                 Key: JBSEAM-349
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-349
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>
> I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:07:44 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Fri, 8 Sep 2006 11:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <8192538.1157728064034.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3345?page=comments#action_12343072 ] 
            
Remy Maucherat commented on JBAS-3345:
--------------------------------------

After fixing an issue with JDT not being included, it seems mostly ok.

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:29:28 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 8 Sep 2006 11:29:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3636) Port
 HASingletonElectionPolicy to Branch_4_0
Message-ID: <26666341.1157729368785.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port HASingletonElectionPolicy to Branch_4_0
--------------------------------------------

                 Key: JBAS-3636
                 URL: http://jira.jboss.com/jira/browse/JBAS-3636
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Alex Fu
             Fix For: JBossAS-4.0.6.CR1




-- 
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

        


From jira-events at jboss.com  Fri Sep  8 11:35:30 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Fri, 8 Sep 2006 11:35:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-61) Apache Tomcat 6.0
In-Reply-To: <21194316.1153309331365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22476837.1157729730591.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-61?page=comments#action_12343073 ] 
            
Remy Maucherat commented on JBWEB-61:
-------------------------------------

Comet API finalization is now going along well.

> Apache Tomcat 6.0
> -----------------
>
>                 Key: JBWEB-61
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-61
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Remy Maucherat
>         Assigned To: Remy Maucherat
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 12:39:27 2006
From: jira-events at jboss.com (Manfred Moser (JIRA))
Date: Fri, 8 Sep 2006 12:39:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-340) Streamline use of
 i18n validation error messages
In-Reply-To: <8577644.1156954063866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9926163.1157733567823.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-340?page=comments#action_12343076 ] 
            
Manfred Moser commented on JBSEAM-340:
--------------------------------------

I tested the hibernate validator like variables and they work fine with using the ValidatorMessages resource bundle in the entity bean and it bubbles up nicely into the Seam based UI. So this works
    @NotNull
    @Length(min = 2, max=100, message="{person.lastName.length}")
    public String getLastName()
    {
        return lastName;
    }

with 
person.lastName.length=Last Name has to be between {min} and {max} characters long.
in ValidatorMessages.propties and messages.properties copied by the build file.

> Streamline use of i18n validation error messages 
> -------------------------------------------------
>
>                 Key: JBSEAM-340
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-340
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: Seam 1.0.1.GA
>            Reporter: Manfred Moser
>         Assigned To: Emmanuel Bernard
>
> As described in the forum post referenced introducing i18n error message from validation of an entity bean does not have an example anywhere and actually only works nicely with a bit of a work around. The situation is that the hibernate validation needs the error message in ValidatorMessages_*.properties and Seam has its properties in messages_*.properties. For the entity bean to work without Seam (e.g. in a unit test that verifies the validation settings) the messages have to exist in the hibnerate resource bundle. For usage in Seam they have to exist in the Seam bundle. For a Seam app to actually start up all properties related to exist in the Hibnerate and the Seam bundles .. which leads to ugly duplication. A fix is to keep all properties in the seam bundles and copy them into the hibernate bundle at build time. The forum post has a ant task. It would however be better if Seam could somehow manage to pass the resources to hibernate or otherwise just automatically include the hibernate bundle. An example of the i18n of the validation message and other annotation based messages should be included in the examples.

-- 
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

       



From jira-events at jboss.com  Fri Sep  8 13:49:31 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 8 Sep 2006 13:49:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1024) Verify theme
 CSS compatible with multiple browsers/OS
In-Reply-To: <12922402.1157647004240.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18168218.1157737771667.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1024?page=all ]

Roy Russo resolved JBPORTAL-1024.
---------------------------------

    Resolution: Done

> Verify theme CSS compatible with multiple browsers/OS
> -----------------------------------------------------
>
>                 Key: JBPORTAL-1024
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1024
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 14:35:32 2006
From: jira-events at jboss.com (Sangeetha Pisharody (JIRA))
Date: Fri, 8 Sep 2006 14:35:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCLUSTER-126) Lookup fails
	during failover
Message-ID: <14759844.1157740532490.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ]

Sangeetha Pisharody updated JBCLUSTER-126:
------------------------------------------

    Affects Version/s: Q2Y6

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBCLUSTER-126
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-126
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>             Fix For: Bugs
>
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534) 
> This happened on our test cluster. 
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 14:51:31 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 8 Sep 2006 14:51:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-126) Lookup fails
	during failover
Message-ID: <18900200.1157741491495.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-126?page=all ]

Brian Stansberry resolved JBCLUSTER-126.
----------------------------------------

    Resolution: Rejected

Please discuss on user forum at http://www.jboss.com/index.html?module=bb&op=viewforum&f=64 before opening a bug.  Also, please file Application Server bugs under the Application Server project, not the Cluster project.  The Cluster project is for high-level planning, and bugs or fixes there can't be associated with specific releases.  Not blaming you for reporting here; it's confusing :)

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBCLUSTER-126
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-126
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>             Fix For: Bugs
>
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534) 
> This happened on our test cluster. 
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 15:15:31 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Fri, 8 Sep 2006 15:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3637) Way to set JNDI
 properties for twiddle
Message-ID: <8081975.1157742931112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Way to set JNDI properties for twiddle
--------------------------------------

                 Key: JBAS-3637
                 URL: http://jira.jboss.com/jira/browse/JBAS-3637
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Owen Taylor
            Priority: Minor


It is frequently useful to be able to set JDNI properties when running twiddle - for example,
you might want to set jnp.disableDiscovery when checking the status of a particular server
that might not be running.

Right now, this is difficult to do. You can export a JBOSS_CLASSPATH
which contains a jndi.properties file before running twiddle.sh, but then you have to
include all the standard jars in it, which is quite annoying.

A pssible fixes would be one of:

 A) A way to prepend elements to JBOSS_CLASSPATH without disabling the default
  construction (also useful for getting a log4j.properties that doesn't drop twiddle.log
  in the cwd, perhaps)
 
 B) A command line option for specifying a particular properties file to load and pass
  to 'new InitialContext()' (slightly more convenient than A)

 C) A command line option to define particular properties:

    twiddle.sh -jnpProperty=jnp.disableDiscovery=true

  (Or some better syntax)

The twiddle code actually does:

         Properties props = new Properties(System.getProperties());
         props.put(Context.PROVIDER_URL, serverURL);
         ctx = new InitialContext(props);

In the case where a server URL is set, so there may have been intention that twiddle.sh -Djnp.disableDiscovery=true
would work, but AFAIK property inheritance doesn't work in that place - only the properties directly in props take 
effect, and system properties won't be looked at in the other code path either.


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 15:57:27 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Fri, 8 Sep 2006 15:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-336) core reteoo
 implementation for 'accumulate'
Message-ID: <25775972.1157745447829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-336?page=all ]

Edson Tirelli resolved JBRULES-336.
-----------------------------------

    Resolution: Done

Fixing minor bugs and finishing the implementation. Commited to trunk in revision #6130:

----------------------
JBRULES-217: add Accumulate Conditional Element

  * JBRULES-336:
    - Fixing minor bugs
    - Updating test cases
  * JBRULES-337:
    - Fixing minor bugs
    - Adding integration tests

  * Removing System.out from test cases
----------------------

Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/Cheesery.java
Sending        drools-compiler/src/test/java/org/drools/Person.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/HelloWorld.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/errors_in_rule.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/evalmodify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/not_with_bindings_rule_test.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/null_behaviour.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_AccumulateModify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_AgendaGroups.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_FunctionInConsequence.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_OrWithBindings.drl
Sending        drools-core/src/main/java/org/drools/common/DefaultAgenda.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Sending        drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data .........................
Committed revision 6130.


> core reteoo implementation for 'accumulate'
> -------------------------------------------
>
>                 Key: JBRULES-336
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-336
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 15:57:27 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Fri, 8 Sep 2006 15:57:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-337) language support
 for 'accumulate'
Message-ID: <20500859.1157745447993.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-337?page=all ]

Edson Tirelli resolved JBRULES-337.
-----------------------------------

    Resolution: Done

Fixing minor bugs and finishing the implementation. Commited to trunk in revision #6130:

----------------------
JBRULES-217: add Accumulate Conditional Element

  * JBRULES-336:
    - Fixing minor bugs
    - Updating test cases
  * JBRULES-337:
    - Fixing minor bugs
    - Adding integration tests

  * Removing System.out from test cases
----------------------

Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaInvokers.stg
Sending        drools-compiler/src/main/resources/org/drools/semantics/java/javaRule.stg
Sending        drools-compiler/src/test/java/org/drools/Cheesery.java
Sending        drools-compiler/src/test/java/org/drools/Person.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/semantics/java/AccumulateTemplateTest.java
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/HelloWorld.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/errors_in_rule.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/evalmodify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/not_with_bindings_rule_test.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/null_behaviour.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_Accumulate.drl
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_AccumulateModify.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_AgendaGroups.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_FunctionInConsequence.drl
Sending        drools-compiler/src/test/resources/org/drools/integrationtests/test_OrWithBindings.drl
Sending        drools-core/src/main/java/org/drools/common/DefaultAgenda.java
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteTuple.java
Sending        drools-core/src/main/java/org/drools/rule/Accumulate.java
Sending        drools-core/src/main/java/org/drools/spi/Accumulator.java
Sending        drools-core/src/test/java/org/drools/reteoo/AccumulateNodeTest.java
Sending        drools-core/src/test/java/org/drools/reteoo/MockAccumulator.java
Transmitting file data .........................
Committed revision 6130.


> language support for 'accumulate'
> ---------------------------------
>
>                 Key: JBRULES-337
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-337
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Mark Proctor
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 16:43:30 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 8 Sep 2006 16:43:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-3) svn move of security
 from jbossas/trunk to jbossas/projects
In-Reply-To: <6196176.1157480847807.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31147412.1157748210404.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-3?page=all ]

Anil Saldhana closed SECURITY-3.
--------------------------------

    Resolution: Done

https://svn.jboss.org/repos/jbossas/projects/security/trunk/

> svn move of security from jbossas/trunk to jbossas/projects
> -----------------------------------------------------------
>
>                 Key: SECURITY-3
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-3
>             Project: JBoss Security
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Perform a svn move of the security module from jbossas/trunk to jbossas/projects

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 17:11:30 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 8 Sep 2006 17:11:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-1) Move source
 repository from trunk to projects
In-Reply-To: <2995519.1157476652735.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1424248.1157749890103.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-1?page=all ]

Anil Saldhana closed SECURITY-1.
--------------------------------

    Resolution: Done

Emailed the dev-list.  Cruisecontrol build has confirmed that HEAD builds with no issues.

http://cruisecontrol.jboss.com/cc/buildresults/jboss-head-jdk-matrix?log=log20060908163425Lbuild.2293

Passing to QA for security project build verification.

> Move source repository from trunk to projects
> ---------------------------------------------
>
>                 Key: SECURITY-1
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-1
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Repository
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> Scott has expressed a desire to see the security project act as the model project to have a SPI and a JBossAS implementation. 
> The first step in this exercize is to move the source repository from jbossas/trunk  to https://svn.jboss.org/repos/jbossas/projects/  (Reference will be the microcontainer project)

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:11:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 8 Sep 2006 18:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1026) Fix Tabs CSS to
 work with existing Navigation CSS
In-Reply-To: <9596533.1157655703858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7439649.1157753489254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1026?page=all ]

Roy Russo resolved JBPORTAL-1026.
---------------------------------

    Resolution: Done

> Fix Tabs CSS to work with existing Navigation CSS
> -------------------------------------------------
>
>                 Key: JBPORTAL-1026
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1026
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:11:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 8 Sep 2006 18:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1027) New Renderer
	for New UI
In-Reply-To: <24226605.1157656063859.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16999451.1157753489362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1027?page=all ]

Roy Russo resolved JBPORTAL-1027.
---------------------------------

    Resolution: Rejected

new renderer not need for new ui, but will be for dnd.

> New Renderer for New UI
> -----------------------
>
>                 Key: JBPORTAL-1027
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1027
>             Project: JBoss Portal
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Develop new Renderer class for new layout/theme.
> The new usability requires additional functionality, that requires a new renderer:
> 1. New icon placement: ie, the remove window icon.
> 2. New region for Adding Content to a page.
> Issues: New renderer will not be compatible with previous themes/layouts.

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:25:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:25:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-596) Lease doesn't work
 if client has two connections opened when using callbacks
Message-ID: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lease doesn't work if client has two connections opened when using callbacks
----------------------------------------------------------------------------

                 Key: JBREM-596
                 URL: http://jira.jboss.com/jira/browse/JBREM-596
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: callbacks
            Reporter: Clebert Suconic
         Assigned To: Tom  Elrod


If you have two connections, one of them is using CallBack the Lease is just stopped.

I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.

Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.

You can look at cruisecontrol results at this URL:

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html

and

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html


I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.



Here is the code:


	   public void testSimplestDurableSubscription() throws Exception
	   {
	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
	      
	      Connection conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();

	      Connection conn2 = cf.createConnection();
	      conn2.setClientID("client2");
	      conn2.start();

	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);

	      MessageProducer prod = s.createProducer(topic);
	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);

	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");

	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
	      
	      
	      for (int i=0;i<10;i++)
	      {
	    	  prod.send(s.createTextMessage("k"+i));
	      }
	      s.commit();

	      conn.close();
	      conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();
	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      durable = s.createDurableSubscriber(topic, "subs1");

	      for (int i=0;i<2;i++)
	      {
	    	  TextMessage tm = (TextMessage)durable.receive(1000);
	    	  assertNotNull(tm);
	    	  s.commit();
	    	  System.out.println(tm.getText());
	    	  assertEquals("k" + i, tm.getText());
	      }
	      
	      //conn.close();-- do not remote this comment. It was meant to not close the connection

	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
	   }


-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:29:27 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:29:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25435734.1157754567110.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Assignee: Tom  Elrod  (was: Clebert Suconic)
    Priority: Critical  (was: Major)

Tom, I'm assigning this task to you but please assign me back when you have closed JBREM-596

> Crash Test failure on Durable Subscriber
> ----------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> DurableSubscriberCrashTest1 and 2 are failing.
> The routine that verifies if a connection is broken is only called upon communication exceptions. 
> If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:31:27 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Fri, 8 Sep 2006 18:31:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-480) update
 documentation with 'accumulate' information
Message-ID: <10536387.1157754687859.JavaMail.jira@cloud.prod.atl2.jboss.com>

update documentation with 'accumulate' information
--------------------------------------------------

                 Key: JBRULES-480
                 URL: http://jira.jboss.com/jira/browse/JBRULES-480
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli




-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:37:28 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:37:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9540756.1157755048862.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970472#3970472

> Crash Test failure on Durable Subscriber
> ----------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> DurableSubscriberCrashTest1 and 2 are failing.
> The routine that verifies if a connection is broken is only called upon communication exceptions. 
> If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 18:37:29 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 8 Sep 2006 18:37:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease doesn't work
 if client has two connections opened when using callbacks
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26536721.1157755049026.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic updated JBREM-596:
----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3970472#3970472

> Lease doesn't work if client has two connections opened when using callbacks
> ----------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>
> If you have two connections, one of them is using CallBack the Lease is just stopped.
> I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.
> Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.
> You can look at cruisecontrol results at this URL:
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html
> and
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html
> I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.
> Here is the code:
> 	   public void testSimplestDurableSubscription() throws Exception
> 	   {
> 	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
> 	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
> 	      
> 	      Connection conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      Connection conn2 = cf.createConnection();
> 	      conn2.setClientID("client2");
> 	      conn2.start();
> 	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      MessageProducer prod = s.createProducer(topic);
> 	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);
> 	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
> 	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");
> 	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
> 	      
> 	      
> 	      for (int i=0;i<10;i++)
> 	      {
> 	    	  prod.send(s.createTextMessage("k"+i));
> 	      }
> 	      s.commit();
> 	      conn.close();
> 	      conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      durable = s.createDurableSubscriber(topic, "subs1");
> 	      for (int i=0;i<2;i++)
> 	      {
> 	    	  TextMessage tm = (TextMessage)durable.receive(1000);
> 	    	  assertNotNull(tm);
> 	    	  s.commit();
> 	    	  System.out.println(tm.getText());
> 	    	  assertEquals("k" + i, tm.getText());
> 	      }
> 	      
> 	      //conn.close();-- do not remote this comment. It was meant to not close the connection
> 	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
> 	   }

-- 
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

        


From jira-events at jboss.com  Fri Sep  8 21:16:27 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 8 Sep 2006 21:16:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-761) Make connecting
 the channel and state transfer an atomic part of startup
Message-ID: <22897707.1157764587331.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make connecting the channel and state transfer an atomic part of startup
------------------------------------------------------------------------

                 Key: JBCACHE-761
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-761
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani


If an exception is thrown during initial state transfer, the channel should be disconnected.  The exception will propagate out of startService(), which in the AS will leave the cache service in an incompletely deployed state.  But the current code leaves the channel connected, leaving a "zombie" member of the group.

Probably need to alter stopService() as well to ensure it can handle an already disconnected channel.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:21:29 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-302) Deadlock with TCP and
 loopback=true
Message-ID: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deadlock with TCP and loopback=true
-----------------------------------

                 Key: JGRP-302
                 URL: http://jira.jboss.com/jira/browse/JGRP-302
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


"TimeScheduler.Thread":
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
        - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.FD.up(FD.java:274)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.Discovery.up(Discovery.java:275)
        at org.jgroups.protocols.MPING.up(MPING.java:152)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
        at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
        at org.jgroups.protocols.TP.doSend(TP.java:934)
        at org.jgroups.protocols.TP.send(TP.java:923)
        - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
        at org.jgroups.protocols.TP.down(TP.java:712)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.Discovery.down(Discovery.java:333)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
        at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
        - locked <0x1056bf90> (a java.lang.Object)
        at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
        - locked <0x1056bf78> (a java.util.Vector)
        at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
        at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
        at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
        at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)


"IncomingMessageHandler (channel=DrawGroupDemo)":
        at org.jgroups.protocols.TP.send(TP.java:922)
        - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
        at org.jgroups.protocols.TP.down(TP.java:712)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.Discovery.down(Discovery.java:333)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.FD.down(FD.java:313)
        at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
        at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
        at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
        - locked <0x1056b9d0> (a java.util.Hashtable)
        at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.FD.up(FD.java:259)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.Discovery.up(Discovery.java:225)
        at org.jgroups.protocols.MPING.up(MPING.java:152)
        at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
        at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
        at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
        at org.jgroups.protocols.TP.access$700(TP.java:45)
        at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
        at java.lang.Thread.run(Thread.java:534)

Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:21:29 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:21:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-302) Deadlock with TCP
 and loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14605943.1157790089453.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-302?page=comments#action_12343099 ] 
            
Bela Ban commented on JGRP-302:
-------------------------------

SOLUTION: pass down ARE-YOU-ALIVE messages in VERIFY_SUSPECT.verifySuspect() outside the scope of the synchronized(suspects) statement

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:23:29 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:23:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-303) Verify that all
 synchronized statements have short scopes
Message-ID: <292182.1157790209387.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

        


From jira-events at jboss.com  Sat Sep  9 04:29:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:29:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-304) Verify that MergeView
 is marshalled/unmarshalled correctly
Message-ID: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>

Verify that MergeView is marshalled/unmarshalled correctly
----------------------------------------------------------

                 Key: JGRP-304
                 URL: http://jira.jboss.com/jira/browse/JGRP-304
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :

public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
        super.readFrom(in);
        short len=in.readShort();
        if(len > 0) {
            View v;
            subgroups=new Vector();
            for(int i=0; i < len; i++) {
                v=new View(); // <========= here 
                v.readFrom(in);
                subgroups.add(v);
            }
        }
    }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:29:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:29:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-304) Verify that
 MergeView is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14289304.1157790568664.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-304?page=comments#action_12343100 ] 
            
Bela Ban commented on JGRP-304:
-------------------------------

SOLUTION: we need to encode the type of view: View or MergeView, for each view in the subgroups, and create either Views or MergeViews accordingly

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 04:35:28 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 04:35:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-304) Verify that MergeView
 is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6310666.1157790928556.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-304?page=all ]

Bela Ban updated JGRP-304:
--------------------------

    Issue Type: Bug  (was: Task)

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:13:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Sat, 9 Sep 2006 08:13:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-762) Configuration
 object enhancements
Message-ID: <17732187.1157804023738.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configuration object enhancements
---------------------------------

                 Key: JBCACHE-762
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-762
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.0


1.  Why isn't there a CacheFactory.createCache() (using the default configuration)
2.  I think it would be useful to have a static method in Configuration which returns the default config, so we could do: Cache c=new DefaultCacheFactory().createCache(Configuration.getDefault())
3.  Configuration should have a copy() or clone() method, so we can reuse a config, and make small modifications
4.  Make Configuration serializable (ship them around ?)

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:39:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-302) Deadlock with TCP
 and loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25077212.1157805583855.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-302?page=comments#action_12343101 ] 
            
Bela Ban commented on JGRP-302:
-------------------------------

Fixed according to solution, still needs to be verified though

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:45:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-305) TCP suspects a member
 P if it encounters an exception sending on the socket to P
Message-ID: <31530499.1157805943841.JavaMail.jira@cloud.prod.atl2.jboss.com>

TCP suspects a member P if it encounters an exception sending on the socket to P
--------------------------------------------------------------------------------

                 Key: JGRP-305
                 URL: http://jira.jboss.com/jira/browse/JGRP-305
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


The transport should not emit suspicions, because that's the task of the failure detection protocol (FD, FD_SOCK). Now, this won't happen unless suspect_on_send_failure is set to true (default=false)

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:45:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:45:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-305) TCP suspects a
 member P if it encounters an exception sending on the socket to P
In-Reply-To: <31530499.1157805943841.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15406062.1157805943966.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-305?page=all ]

Bela Ban resolved JGRP-305.
---------------------------

    Resolution: Done

> TCP suspects a member P if it encounters an exception sending on the socket to P
> --------------------------------------------------------------------------------
>
>                 Key: JGRP-305
>                 URL: http://jira.jboss.com/jira/browse/JGRP-305
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> The transport should not emit suspicions, because that's the task of the failure detection protocol (FD, FD_SOCK). Now, this won't happen unless suspect_on_send_failure is set to true (default=false)

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:51:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13333067.1157806303835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban updated JGRP-302:
--------------------------

    Attachment: bela_org.xml

TCP config which caused the deadlock

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:51:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23918332.1157806303944.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban updated JGRP-302:
--------------------------

    Attachment:     (was: bela_org.xml)

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:53:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28438443.1157806423793.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban updated JGRP-302:
--------------------------

    Attachment: bela_org.xml

TCP config which caused the deadlock.
To reproduce:
- Start Draw with bela.xml on A,B,C
- Pull the plug on A and B
- C will have the deadlock

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>         Attachments: bela_org.xml
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 08:59:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 08:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-306) FD_SOCK doesn't work
 with TCP and loopback=true
Message-ID: <28243156.1157806783784.JavaMail.jira@cloud.prod.atl2.jboss.com>

FD_SOCK doesn't work with TCP and loopback=true
-----------------------------------------------

                 Key: JGRP-306
                 URL: http://jira.jboss.com/jira/browse/JGRP-306
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


When pulling the plug. Could be the result of http://jira.jboss.com/jira/browse/JGRP-302. If that's the case, then this issue here is not a bug

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:17:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 09:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-304) Verify that
 MergeView is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13419046.1157807863893.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-304?page=comments#action_12343104 ] 
            
Bela Ban commented on JGRP-304:
-------------------------------

The unit test which fails is StreamableTest.testMergeView()

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:29:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 09:29:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-304) Verify that
 MergeView is marshalled/unmarshalled correctly
In-Reply-To: <29455564.1157790568558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31808315.1157808583795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-304?page=all ]

Bela Ban resolved JGRP-304.
---------------------------

    Resolution: Done

fixed according to proposed solution

> Verify that MergeView is marshalled/unmarshalled correctly
> ----------------------------------------------------------
>
>                 Key: JGRP-304
>                 URL: http://jira.jboss.com/jira/browse/JGRP-304
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If MergeView contains subgroups who have Views and *MergeViews*, then MergeView.readFrom() is probably incorrect because readFrom() explicitly creates a *View*, not a *MergView* :
> public void readFrom(DataInputStream in) throws IOException, IllegalAccessException, InstantiationException {
>         super.readFrom(in);
>         short len=in.readShort();
>         if(len > 0) {
>             View v;
>             subgroups=new Vector();
>             for(int i=0; i < len; i++) {
>                 v=new View(); // <========= here 
>                 v.readFrom(in);
>                 subgroups.add(v);
>             }
>         }
>     }

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:53:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 9 Sep 2006 09:53:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3434) Produce the
 Installer for 4.0.5.GA
In-Reply-To: <26621920.1153999031462.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23068295.1157810024391.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3434?page=all ]

Dimitris Andreadis updated JBAS-3434:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)
          Summary: Produce the Installer for 4.0.5.GA  (was: Produce the Installer for 4.0.5.CR1)

Agreed that installer will only be released only for production releases (GA/SP), not candidate releases.

> Produce the Installer for 4.0.5.GA
> ----------------------------------
>
>                 Key: JBAS-3434
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3434
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>            Reporter: Dimitris Andreadis
>         Assigned To: Alex Pinkin
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Task to hold installer related issues for this release.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 09:59:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 09:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-302) Deadlock with TCP and
 loopback=true
In-Reply-To: <4508851.1157790089338.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26412536.1157810383806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-302?page=all ]

Bela Ban resolved JGRP-302.
---------------------------

    Resolution: Done

Tested successfully on 2 boxes (3 members on one, 2 on the others).
Pulled the plug on one box, then on the other, then on both
Pulled the plug on the switch
Pulled the plug on the switch's power supply
SUCCESS

> Deadlock with TCP and loopback=true
> -----------------------------------
>
>                 Key: JGRP-302
>                 URL: http://jira.jboss.com/jira/browse/JGRP-302
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>         Attachments: bela_org.xml
>
>
> "TimeScheduler.Thread":
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:227)
>         - waiting to lock <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:274)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:275)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.BasicTCP.sendToSingleMember(BasicTCP.java:67)
>         at org.jgroups.protocols.BasicTCP.sendToAllMembers(BasicTCP.java:41)
>         at org.jgroups.protocols.TP.doSend(TP.java:934)
>         at org.jgroups.protocols.TP.send(TP.java:923)
>         - locked <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD$BroadcastTask.run(FD.java:671)
>         at org.jgroups.protocols.FD$Broadcaster.startBroadcastTask(FD.java:563)
>         - locked <0x1056bf90> (a java.lang.Object)
>         at org.jgroups.protocols.FD$Broadcaster.addSuspectedMember(FD.java:590)
>         - locked <0x1056bf78> (a java.util.Vector)
>         at org.jgroups.protocols.FD$Monitor.run(FD.java:515)
>         at org.jgroups.util.TimeScheduler._run(TimeScheduler.java:397)
>         at org.jgroups.util.TimeScheduler.access$000(TimeScheduler.java:44)
>         at org.jgroups.util.TimeScheduler$Loop.run(TimeScheduler.java:141)
> "IncomingMessageHandler (channel=DrawGroupDemo)":
>         at org.jgroups.protocols.TP.send(TP.java:922)
>         - waiting to lock <0x1055e088> (a org.jgroups.util.ExposedByteArrayOutputStream)
>         at org.jgroups.protocols.TP.down(TP.java:712)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.Discovery.down(Discovery.java:333)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.MERGE2.down(MERGE2.java:208)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.FD.down(FD.java:313)
>         at org.jgroups.stack.Protocol.receiveDownEvent(Protocol.java:517)
>         at org.jgroups.stack.Protocol.passDown(Protocol.java:551)
>         at org.jgroups.protocols.VERIFY_SUSPECT.verifySuspect(VERIFY_SUSPECT.java:234)
>         - locked <0x1056b9d0> (a java.util.Hashtable)
>         at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:131)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.FD.up(FD.java:259)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.MERGE2.up(MERGE2.java:163)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.Discovery.up(Discovery.java:225)
>         at org.jgroups.protocols.MPING.up(MPING.java:152)
>         at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:488)
>         at org.jgroups.stack.Protocol.passUp(Protocol.java:538)
>         at org.jgroups.protocols.TP.handleIncomingMessage(TP.java:905)
>         at org.jgroups.protocols.TP.access$700(TP.java:45)
>         at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1329)
>         at java.lang.Thread.run(Thread.java:534)
> Found 1 deadlock.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:03:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:03:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-306) FD_SOCK doesn't work
 with TCP and loopback=true
In-Reply-To: <28243156.1157806783784.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19677837.1157810623808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-306?page=all ]

Bela Ban resolved JGRP-306.
---------------------------

    Resolution: Done

Depended on 302. Once 302 was fixed, this issue disappeared

> FD_SOCK doesn't work with TCP and loopback=true
> -----------------------------------------------
>
>                 Key: JGRP-306
>                 URL: http://jira.jboss.com/jira/browse/JGRP-306
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> When pulling the plug. Could be the result of http://jira.jboss.com/jira/browse/JGRP-302. If that's the case, then this issue here is not a bug

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:17:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-307) Run testsuite in
	Fedore Core 3
Message-ID: <9618913.1157811463886.JavaMail.jira@cloud.prod.atl2.jboss.com>

Run testsuite in Fedore Core 3
------------------------------

                 Key: JGRP-307
                 URL: http://jira.jboss.com/jira/browse/JGRP-307
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Optional
             Fix For: 2.4


A user reported some failures

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:33:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-308) Upgrade
 commons-logging from 1.0.3 to 1.1.0
Message-ID: <22502118.1157812423881.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade commons-logging from 1.0.3 to 1.1.0
-------------------------------------------

                 Key: JGRP-308
                 URL: http://jira.jboss.com/jira/browse/JGRP-308
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.5


Needs some testing

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 10:33:44 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 9 Sep 2006 10:33:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-309) Upgrade log4j from
	1.2.8 to 1.2.13
Message-ID: <6267936.1157812424014.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade log4j from 1.2.8 to 1.2.13
----------------------------------

                 Key: JGRP-309
                 URL: http://jira.jboss.com/jira/browse/JGRP-309
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.5


Need some testing

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 11:15:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 9 Sep 2006 11:15:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3605) test failures
 org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase
 (jrockit)
In-Reply-To: <9882655.1157134903814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23677316.1157814943847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3605?page=all ]

Dimitris Andreadis closed JBAS-3605.
------------------------------------

         Assignee: Dimitris Andreadis
    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

      // JBAS-3605, the execution order of tests in this test case is important
      // so it must be defined explicitly when running under some JVMs
      TestSuite suite = new TestSuite();
      suite.addTest(new JMXInvokerUnitTestCase("testGetSomething"));
      suite.addTest(new JMXInvokerUnitTestCase("testGetCustom"));
      suite.addTest(new JMXInvokerUnitTestCase("testGetCustomXMBean"));
      suite.addTest(new JMXInvokerUnitTestCase("testGetXMBeanInfo"));
      suite.addTest(new JMXInvokerUnitTestCase("testXMBeanDoSomething"));
      suite.addTest(new JMXInvokerUnitTestCase("testSetCustom"));
      suite.addTest(new JMXInvokerUnitTestCase("testClassNotFoundException"));
      suite.addTest(new JMXInvokerUnitTestCase("testNotification"));
      suite.addTest(new JMXInvokerUnitTestCase("testNotificationWithBadListener"));
      suite.addTest(new JMXInvokerUnitTestCase("testServerInfoViaHttp"));
      
      return getDeploySetup(suite, "invoker-adaptor-test.ear");

> test failures org.jboss.test.jmx.test.JMXInvokerUnitTestCase/SecureJMXInvokerUnitTestCase (jrockit)
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3605
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3605
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testGetCustom Failure expected:<InitialValue> but was:<changed>
> junit.framework.ComparisonFailure: expected:<InitialValue> but was:<changed>
> 	at org.jboss.test.jmx.test.JMXInvokerUnitTestCase.testGetCustom(JMXInvokerUnitTestCase.java:85)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 11:43:28 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 9 Sep 2006 11:43:28 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3604) 2 failed tests -
 org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
In-Reply-To: <19803940.1157134663902.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8470678.1157816608737.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3604?page=all ]

Dimitris Andreadis closed JBAS-3604.
------------------------------------

         Assignee: Dimitris Andreadis
       Resolution: Done
    Fix Version/s: JBossAS-5.0.0.Beta

The execution order of tests in this test case is important so it must be defined explicitly when running under some JVMs

> 2 failed tests - org.jboss.test.jmx.test.DeployXMBeanUnitTestCase (jrockit)
> ---------------------------------------------------------------------------
>
>                 Key: JBAS-3604
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3604
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testPersistentJndiXMBean Error Hello not bound
> javax.naming.NameNotFoundException: Hello not bound
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
> 	at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
> 	at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
> 	at org.jnp.server.NamingServer.lookup(NamingServer.java:296)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
> 	at org.jboss.naming.NamingService.invoke(NamingService.java:354)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.test.jmx.interceptors.JNDIPersistence.invoke(JNDIPersistence.java:114)
> 	at org.jboss.test.jmx.interceptors.JNDISecurity.invoke(JNDISecurity.java:130)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Unknown Source)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Lorg.jboss.invocation.Invocation;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:133)
> 	at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 	at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 	at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 	at org.jboss.proxy.ClientMethodInterceptor.invoke(ClientMethodInterceptor.java:74)
> 	at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 	at $Proxy1.lookup(Ljavax.naming.Name;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testPersistentJndiXMBean(DeployXMBeanUnitTestCase.java:520)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
>  testSecuredJndiXMBean Failure Was able to invoke secretEcho
> junit.framework.AssertionFailedError: Was able to invoke secretEcho
> 	at org.jboss.test.jmx.test.DeployXMBeanUnitTestCase.testSecuredJndiXMBean(DeployXMBeanUnitTestCase.java:459)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Sat Sep  9 11:53:27 2006
From: jira-events at jboss.com (Andreas Mueller (JIRA))
Date: Sat, 9 Sep 2006 11:53:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3343) JCA 1.5 Resource
 Adapter Config Properties cannot be specified
Message-ID: <31032837.1157817207745.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3343?page=comments#action_12343111 ] 
            
Andreas Mueller commented on JBAS-3343:
---------------------------------------

In which release will this issue be fixed? 

The fix is very important because no JCA RA can be properly configured except with cracking the rar and overwriting the default props.

> JCA 1.5 Resource Adapter Config Properties cannot be specified
> --------------------------------------------------------------
>
>                 Key: JBAS-3343
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3343
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: All.
>            Reporter: Andreas Mueller
>         Assigned To: Weston Price
>         Attachments: ra.xml
>
>
> A JCA 1.5 resource adapter might contain config properties in ra.xml. It is not possible in JBoss to override them with -ds.xml file.
> For example, here is an excert of SwiftMQ's intraVM ra.xml:
>   <resourceadapter>
>     <resourceadapter-class>
>       com.swiftmq.connector.v15.ResourceAdapterImpl
>     </resourceadapter-class>
>     <config-property>
>       <config-property-name>ProviderURL</config-property-name>
>       <config-property-type>java.lang.String</config-property-type>
>       <config-property-value>smqp://intravm/timeout=10000</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>IntraVM</config-property-name>
>       <config-property-type>java.lang.Boolean</config-property-type>
>       <config-property-value>true</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>DebugMode</config-property-name>
>       <config-property-type>java.lang.Boolean</config-property-type>
>       <config-property-value>false</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>RouterWorkingDirectory</config-property-name>
>       <config-property-type>java.lang.String</config-property-type>
>       <config-property-value>&lt;swiftmq_dir&gt;/scripts/unix</config-property-value>
>     </config-property>
>     <config-property>
>       <config-property-name>ConfigurationFilename</config-property-name>
>       <config-property-type>java.lang.String</config-property-type>
>       <config-property-value>../../config/router1/routerconfig.xml</config-property-value>
>     </config-property>
> It is not possible to overwrite them during deployment. It is only possible to specify the config properties of the ManagedConnectionFactory in -ds.xml.

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 13:31:27 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sat, 9 Sep 2006 13:31:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3456) JSP page not compiled
 while using JDK5.0_7 in JBoss 4.0.2
In-Reply-To: <21972994.1154507351343.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2401909.1157823087532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3456?page=all ]

Scott M Stark closed JBAS-3456.
-------------------------------

    Resolution: Out of Date

See the " Using JDK5 Features in JSP Pages" section of:
http://wiki.jboss.org/wiki/Wiki.jsp?page=402UpgradeIssues


> JSP page not compiled while using JDK5.0_7 in JBoss 4.0.2
> ---------------------------------------------------------
>
>                 Key: JBAS-3456
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3456
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP, JBoss 4.0.2, JDK 5.0_7 (the lastest version)
>            Reporter: Sasi Levi
>
> I deployed my war application and tried to run JSP that include feature of JDK 5.0, I got error of syntax.
> The code is List<String> list = new ArrayList<String>();
> I checked the run script of the JBoss and I saw  mention of the JAVAC for the JSP, by default is to support JDK of sun.
>        

-- 
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

        


From jira-events at jboss.com  Sat Sep  9 22:45:27 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Sat, 9 Sep 2006 22:45:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease doesn't work
 if client has two connections opened when using callbacks
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27251787.1157856327813.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Tom  Elrod updated JBREM-596:
-----------------------------

        Fix Version/s: 2.2.0.Beta1 (Bluto)
    Affects Version/s: 2.0.0.GA (Boon)

> Lease doesn't work if client has two connections opened when using callbacks
> ----------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you have two connections, one of them is using CallBack the Lease is just stopped.
> I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.
> Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.
> You can look at cruisecontrol results at this URL:
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html
> and
> http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html
> I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.
> Here is the code:
> 	   public void testSimplestDurableSubscription() throws Exception
> 	   {
> 	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
> 	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
> 	      
> 	      Connection conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      Connection conn2 = cf.createConnection();
> 	      conn2.setClientID("client2");
> 	      conn2.start();
> 	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      MessageProducer prod = s.createProducer(topic);
> 	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);
> 	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
> 	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");
> 	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
> 	      
> 	      
> 	      for (int i=0;i<10;i++)
> 	      {
> 	    	  prod.send(s.createTextMessage("k"+i));
> 	      }
> 	      s.commit();
> 	      conn.close();
> 	      conn = cf.createConnection();
> 	      conn.setClientID("client1");
> 	      conn.start();
> 	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
> 	      durable = s.createDurableSubscriber(topic, "subs1");
> 	      for (int i=0;i<2;i++)
> 	      {
> 	    	  TextMessage tm = (TextMessage)durable.receive(1000);
> 	    	  assertNotNull(tm);
> 	    	  s.commit();
> 	    	  System.out.println(tm.getText());
> 	    	  assertEquals("k" + i, tm.getText());
> 	      }
> 	      
> 	      //conn.close();-- do not remote this comment. It was meant to not close the connection
> 	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
> 	   }

-- 
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

        


From jira-events at jboss.com  Sun Sep 10 02:47:30 2006
From: jira-events at jboss.com (Basel Al-Mustafa (JIRA))
Date: Sun, 10 Sep 2006 02:47:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-350) High conversation
 state number causes ui:repeat to show a single item
Message-ID: <852986.1157870850894.JavaMail.jira@cloud.prod.atl2.jboss.com>

High conversation state number causes ui:repeat to show a single item
---------------------------------------------------------------------

                 Key: JBSEAM-350
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-350
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.1
         Environment: CentOS i686, JDK 1.5.0_06-b05, MyFaces 1.1.3, Facelets 1.1.11, JBoss 4.0.4 with EJB3 RC8 FD
            Reporter: Basel Al-Mustafa


When the conversation state number goes up to around 4750 the ui:repeat element stops showing the compete list of items. Rather than that only a single item is displayed even though both of the database query and the SLSB page action return several items. The production server log and the source code can be found in the associated JBoss Forum Reference.

-- 
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

        


From MAILER-DAEMON at lists.jboss.org  Sun Sep 10 09:33:49 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Sun, 10 Sep 2006 09:33:49 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609101333.k8ADXnXC027312@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From jira-events at jboss.com  Sun Sep 10 17:34:27 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sun, 10 Sep 2006 17:34:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-444) patch to support
 Notes attribute on decision table Package
In-Reply-To: <9769524.1156268351914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28000592.1157924067855.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-444?page=all ]

Mark Proctor updated JBRULES-444:
---------------------------------

        Fix Version/s: 3.0.5
                           (was: 3.0.4)
    Affects Version/s:     (was: 3.0.4)

> patch to support Notes attribute on decision table Package
> ----------------------------------------------------------
>
>                 Key: JBRULES-444
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-444
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: G?bor Lipt?k
>         Assigned To: Mark Proctor
>            Priority: Optional
>             Fix For: 3.0.5
>
>         Attachments: jboss_rules_decisiontable_package_notes.diff
>
>
> patch attached

-- 
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

        


From jira-events at jboss.com  Sun Sep 10 17:48:30 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sun, 10 Sep 2006 17:48:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-481)
 LeftInputAdater.updateNewNode does incorrect propagation
Message-ID: <22024033.1157924910095.JavaMail.jira@cloud.prod.atl2.jboss.com>

LeftInputAdater.updateNewNode does incorrect propagation
--------------------------------------------------------

                 Key: JBRULES-481
                 URL: http://jira.jboss.com/jira/browse/JBRULES-481
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Reteoo
    Affects Versions: 3.0.4
            Reporter: Mark Proctor
         Assigned To: Edson Tirelli
             Fix For: 3.0.5, 3.1-m1


        // Get the newly attached TupleSink
        final TupleSink sink = (TupleSink) getTupleSinks().get( getTupleSinks().size() - 1 );

        // Iterate the memory and assert all tuples into the newly attached TupleSink
        final Map memory = (Map) workingMemory.getNodeMemory( this );
        for ( final Iterator it = memory.values().iterator(); it.hasNext(); ) {
            final LinkedList list = (LinkedList) it.next();
            for ( LinkedListNode node = list.getFirst(); node != null; node = node.getNext() ) {
                sink.assertTuple( (ReteTuple) ((LinkedListObjectWrapper) node).getObject(),
                                  context,
                                  workingMemory );
            }
        }

We get the last Sink but then we send through ALL tuples in the list to that single sink. yet we know that each tuple is for a specific sink. we instead should grab the handle and create a new tuple which we add to the list.

-- 
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

        


From jira-events at jboss.com  Sun Sep 10 21:08:43 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Sun, 10 Sep 2006 21:08:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-482) ACTIVATION-GROUP
 not processed by ActionType
Message-ID: <16529337.1157936923871.JavaMail.jira@cloud.prod.atl2.jboss.com>

ACTIVATION-GROUP not processed by ActionType
--------------------------------------------

                 Key: JBRULES-482
                 URL: http://jira.jboss.com/jira/browse/JBRULES-482
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Steven Williams
         Assigned To: Mark Proctor


The code in ActionType has the following:
 
else if ( value.toUpperCase().startsWith( "X" ) || value.toUpperCase().equals( "ACTIVATION-GROUP" ) )

but above this is a check for startsWith("A") to catch Actions which will always take precedence. Maybe it would be better to check for the full names first and then for the single letter option.

In the documentation it actually specifies that "XOR-GROUP" should be used, so the other option may be to just remove the "ACTIVATION-GROUP" check, however the current code means new options (such as agenda group for instance) would have to use letters that don't really make sense.


-- 
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

        


From c11 at fullmailmarket.com  Mon Sep 11 00:41:10 2006
From: c11 at fullmailmarket.com (Carrier 179 (www.179.cl))
Date: Mon, 11 Sep 2006 00:41:10 -0400
Subject: [jboss-jira] SOLO EL CARRIER 179 LE DA CREDITO A SU
	LLAMADA...APROVECHE
Message-ID: <200609110441.k8B4fAc6006009@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060911/1e38f1db/attachment-0001.html 

From workfromhome at yahoo.com  Mon Sep 11 12:22:55 2006
From: workfromhome at yahoo.com (ªÔ³Õ¹Øª)
Date: Mon, 11 Sep 2006 12:22:55
Subject: [jboss-jira] =?iso-8859-1?q?=C3=E9=CD=B9=E6_=CA=C3=E9=D2=A7=24?=
Message-ID: <200609110522.k8B5MtAD006679@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060911/c53cb126/attachment-0001.html 

From MAILER-DAEMON at lists.jboss.org  Mon Sep 11 03:09:04 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Mon, 11 Sep 2006 03:09:04 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609110709.k8B794Os008196@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From MAILER-DAEMON at lists.jboss.org  Mon Sep 11 03:09:33 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Mon, 11 Sep 2006 03:09:33 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609110709.k8B79Xpa008229@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From jira-events at jboss.com  Mon Sep 11 03:22:44 2006
From: jira-events at jboss.com (Roel Adriaensens (JIRA))
Date: Mon, 11 Sep 2006 03:22:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3638) Extra option for
 Hibernate MBean
 to specify which modules should be scanned for hbm files
Message-ID: <6237533.1157959364112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Extra option for Hibernate MBean to specify which modules should be scanned for hbm files
-----------------------------------------------------------------------------------------

                 Key: JBAS-3638
                 URL: http://jira.jboss.com/jira/browse/JBAS-3638
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Hibernate service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Roel Adriaensens
         Assigned To: Steve Ebersole


We have an ear which contains a set of modules and multiple hibernate session factories (via Hibernate MBean). The complication is that a session factory might need hbm files from multiple modules. This is not possible now since the Hibernate MBean will scan either only the har module or the complete ear. 
So it would be nice if the JBoss Hibernate MBean would provide the option to specify which modules (jars) of the ear must be scanned for hbm mapping files. 

Now, we can't use the option of having multiple *.har modules  in the *.ear, with one *.har for each session factory. We have different projects and each project leads to an artifact (eg. jar, har,sar,...). Some of those projects must use the same session factory, but the mapping files are distributed over multiple artifacts (projects). So it's not possible to have *.har for each of the session factories. Also if we should stick to the *.har, we should split every project into a 'persistence unit' (-> the har) and a 'ejb' jar (which contains the ejb3 session beans etc..). We also don't want to have one project for things that correspond to one session factory. There are different sets of mapping files that are maintained by different teams, but actually belong to the same session factory. 

The alternative would be to have a *.ear for each session factory and then turn on the scanning of the entire *.ear. 
But to me it seems better to have one *.ear that contains multiple modules and multiple session factories + the option for each session factory to indicate which modules should be scanned for mapping files.





-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:30:43 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Mon, 11 Sep 2006 03:30:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-483) Open Decision
 Table API to allow custom RuleSheetListeners
Message-ID: <21379798.1157959843818.JavaMail.jira@cloud.prod.atl2.jboss.com>

Open Decision Table API to allow custom RuleSheetListeners
----------------------------------------------------------

                 Key: JBRULES-483
                 URL: http://jira.jboss.com/jira/browse/JBRULES-483
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Steven Williams
         Assigned To: Mark Proctor


I have a need for a different format for my decision tables - basically instead of the current format with one row per rule with conditions across the top I need to support a matrix-like structure where both the horizontal and the vertical axes represent conditions and the intersection represents the action. In order to do this I created my own MatrixRuleSheetListener inheriting from RuleSheetListener and overriding certain methods. This all works fine however I had to hack the drools code a little to allow me to do it. I was wondering if it would be possible to open up the API to allow this.

Specifically:

1. add method to org.drools.decisiontable.parser.RuleSheetListener
    protected void addRule(Rule rule)
    {
        this._ruleList.add(rule);
    }
2. add empty protected methods preInitRuleTable(row, column, value) and postInitRuleTable(row, column, value, rule) to org.drools.decisiontable.parser.RuleSheetListener which are called from the start and end of the initRuleTable method.
3. Add agendaGroup property to org.drools.decisiontable.model.Rule
4. Add a new method compile(InputStream, InputType, RuleSheetListener) to org.drools.decisiontable.SpreadsheetCompiler

I have attached these changes to this request.

Steve

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:44:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 11 Sep 2006 03:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-310) Update training to
 use latest version
Message-ID: <13709843.1157960683871.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update training to use latest version
-------------------------------------

                 Key: JGRP-310
                 URL: http://jira.jboss.com/jira/browse/JGRP-310
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.5


- Include 2.5
- Change the labs/slides to use the Receiver (push approach)
- Possibly include a Multiplexer example

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:44:44 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Mon, 11 Sep 2006 03:44:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-483) Open Decision
 Table API to allow custom RuleSheetListeners
In-Reply-To: <21379798.1157959843818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17037718.1157960684105.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-483?page=all ]

Steven Williams updated JBRULES-483:
------------------------------------

    Attachment: RuleSheetListener.java
                SpreadsheetCompiler.java
                Rule.java

Changed files for request

> Open Decision Table API to allow custom RuleSheetListeners
> ----------------------------------------------------------
>
>                 Key: JBRULES-483
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-483
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Steven Williams
>         Assigned To: Mark Proctor
>         Attachments: Rule.java, RuleSheetListener.java, SpreadsheetCompiler.java
>
>
> I have a need for a different format for my decision tables - basically instead of the current format with one row per rule with conditions across the top I need to support a matrix-like structure where both the horizontal and the vertical axes represent conditions and the intersection represents the action. In order to do this I created my own MatrixRuleSheetListener inheriting from RuleSheetListener and overriding certain methods. This all works fine however I had to hack the drools code a little to allow me to do it. I was wondering if it would be possible to open up the API to allow this.
> Specifically:
> 1. add method to org.drools.decisiontable.parser.RuleSheetListener
>     protected void addRule(Rule rule)
>     {
>         this._ruleList.add(rule);
>     }
> 2. add empty protected methods preInitRuleTable(row, column, value) and postInitRuleTable(row, column, value, rule) to org.drools.decisiontable.parser.RuleSheetListener which are called from the start and end of the initRuleTable method.
> 3. Add agendaGroup property to org.drools.decisiontable.model.Rule
> 4. Add a new method compile(InputStream, InputType, RuleSheetListener) to org.drools.decisiontable.SpreadsheetCompiler
> I have attached these changes to this request.
> Steve

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 03:56:43 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Mon, 11 Sep 2006 03:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-148) Include Tomcat's
 SavedRequest
 object into the replication process in a Jboss-Tomcat clustered environment
 to allow proper Single Sign On capabilities
Message-ID: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>

Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
-----------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBCLUSTER-148
                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
             Project: JBoss Clustering
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: Q2Y6
         Environment: independent
            Reporter: Alberto Rodriguez
         Assigned To: Brian Stansberry
            Priority: Optional


In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.

Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.

The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:42:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:42:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2644) Revisit the use of
 the jndi bindings in the tomcat server.xml
Message-ID: <23320001.1157964163934.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2644?page=all ]

Dimitris Andreadis updated JBAS-2644:
-------------------------------------

      Component/s: Web (Tomcat) service
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Remy Maucherat

Remy could provide input for this, for the next release.

> Revisit the use of the jndi bindings in the tomcat server.xml
> -------------------------------------------------------------
>
>                 Key: JBAS-2644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We have never supported the declaration of jndi bindings from the tomcat server.xml because we do not use the tomcat jndi service. We should look at whether such bindings just work or can be made to work as a portability aide in moving from standalone tomcat to embedded tomcat.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:42:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:42:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2845) Look at supporting
 web session password update for password change
Message-ID: <25158729.1157964164115.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2845?page=all ]

Dimitris Andreadis updated JBAS-2845:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Anil Saldhana

Anil could provide input, for the next CR release.

> Look at supporting web session password update for password change
> ------------------------------------------------------------------
>
>                 Key: JBAS-2845
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2845
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.6.CR1
>
>
> A common problem  for form authentication is wanting to have a password change feature that does not require a logout/login cycle to update the session id/password association. We need to look into whether there is a secure way to support updating the session password to avoid this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:44:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:44:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2895) Extend
 SecureIdentityLoginModule to externalize the secret
Message-ID: <19664548.1157964283902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2895?page=all ]

Dimitris Andreadis updated JBAS-2895:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Extend SecureIdentityLoginModule to externalize the secret
> ----------------------------------------------------------
>
>                 Key: JBAS-2895
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2895
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Security
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The SecureIdentityLoginModule is a simple security by obscurity approach to hiding the jca password. Having the secret used by the PBE externalized with an ability to hash it reversibly would make this more flexible.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:44:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:44:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3019) Add support for CRL
 validation to the certificate based login modules
Message-ID: <26070929.1157964284077.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3019?page=all ]

Dimitris Andreadis updated JBAS-3019:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Anil Saldhana

Anil could look at this for the next release.

> Add support for CRL validation to the certificate based login modules
> ---------------------------------------------------------------------
>
>                 Key: JBAS-3019
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3019
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We need to add support for validating certificates against certificate revocation lists (CRLs).

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:48:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:48:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3022) Add support for
 configuring a DefaultUncaughtExceptionHandler
Message-ID: <10087963.1157964523782.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3022?page=all ]

Dimitris Andreadis updated JBAS-3022:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Add support for configuring a DefaultUncaughtExceptionHandler
> -------------------------------------------------------------
>
>                 Key: JBAS-3022
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3022
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Logging, MicroContainer bus
>            Reporter: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Apparently there can be bad interaction between the jdk default UncaughtExceptionHandler and logging appenders. We should have the ability to install a handler that integrates better with our logging layer.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:50:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:50:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2249) Cleanup the
 org.jboss.naming packaging
Message-ID: <20392635.1157964643905.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2249?page=all ]

Dimitris Andreadis updated JBAS-2249:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Cleanup the org.jboss.naming packaging
> --------------------------------------
>
>                 Key: JBAS-2249
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2249
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Build System, Naming
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Trying to use the jndi naming service in a minimal configuration requires the full jboss.jar. The naming classes should just be merged into the naming module and jnpserver.jar.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:50:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:50:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2340) Development mode
Message-ID: <5981611.1157964644144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2340?page=all ]

Dimitris Andreadis updated JBAS-2340:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Development mode
> ----------------
>
>                 Key: JBAS-2340
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2340
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: System service
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> There are a number of places in the system that have a "development mode" flag or "debug" flag
> which is usually turned on by default.
> We should add a system property that can be configured via a command line option on run.[sh|.bat]
> that is referenced in the configuration.
> It would then be trivial to do:
> ./run.sh --production

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 04:52:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 04:52:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2402) EAR deployer does
 not process MANIFEST.MF correctly
Message-ID: <28058203.1157964764047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2402?page=all ]

Dimitris Andreadis updated JBAS-2402:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Feature requests to the next release

> EAR deployer does not process MANIFEST.MF correctly
> ---------------------------------------------------
>
>                 Key: JBAS-2402
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2402
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
>         Environment: Windows 2000 AS, SUN JDK 1.5_04
>            Reporter: Alex Pavlov
>             Fix For: JBossAS-4.0.6.CR1
>
>
> EAR deployer failed to process MANIFEST.MF, bundled with EAR - instead of loading jars from EAR content it will try to locate referenced files in ${jboss.server.home}/deploy  directory.
> EAR layout:
>  Directory of C:\java\jboss\server\default\deploy\ear-rpa.ear
> 10/26/2005  01:14p      <DIR>          .
> 10/26/2005  01:14p      <DIR>          ..
> 10/26/2005  01:09p             227,260 ejb-pwc.jar
> 10/26/2005  01:09p              39,997 ejb-rpatask.jar
> 10/26/2005  01:13p      <DIR>          lib
> 10/26/2005  01:13p      <DIR>          META-INF
> 10/26/2005  01:14p      2,498,160         war-rpa.war
>                2 File(s)        267,257 bytes
>  Directory of C:\java\jboss\server\default\deploy\ear-rpa.ear\lib
> 10/26/2005  01:13p      <DIR>          .
> 10/26/2005  01:13p      <DIR>          ..
> 10/26/2005  01:09p                 324 app-classpath.jar
> 10/26/2005  01:09p              39,523 commons-pool-1.1.jar
> 10/26/2005  01:09p             187,037 edx_client.jar
> 10/26/2005  01:09p             679,520 edx_common.jar
> 10/26/2005  01:09p             120,477 edx_rpa.jar
> 10/26/2005  01:09p              11,408 edx_system.jar
> 10/26/2005  01:09p          11,053,816 jrulesall.jar
> 10/26/2005  01:09p             350,627 log4j-1.2.11.jar
> 10/26/2005  01:09p              40,526 logging.jar
> 10/26/2005  01:09p              44,648 sam.jar
>               10 File(s)     12,527,906 bytes
>  Directory of C:\java\jboss\server\default\deploy\ear-rpa.ear\META-INF
> 10/26/2005  01:13p      <DIR>          .
> 10/26/2005  01:13p      <DIR>          ..
> 10/26/2005  02:00p                 487 application.xml
> 10/26/2005  01:10p                 252 MANIFEST.MF
>                2 File(s)            739 bytes
> EAR's MANIFEST file :
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.2
> Created-By: 1.4.2_06-b03 (Sun Microsystems Inc.)
> Built-By: apavlov
> Implementation-Title: rpa
> Implementation-Version: 5.0
> Class-Path: lib/app-classpath.jar
> Fragment of server log file:
> 2005-10-25 17:03:48,153 DEBUG [org.jboss.web.tomcat.tc5.jasper.TagLibCache] Scanning for tlds in: file:/C:/java/jboss/server/default/deploy/jbossweb-tomcat55.sar/jsf-libs/myfaces-impl.jar
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.deployment.MainDeployer] Undeploying file:/C:/java/jboss/server/default/deploy/edx_rpa.jar
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] Unregistering cl=org.jboss.mx.loading.UnifiedClassLoader3 at d0005e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45781edx_rpa.jar ,addedOrder=43}
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] UnifiedLoaderRepository removed(true) org.jboss.mx.loading.UnifiedClassLoader3 at d0005e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45781edx_rpa.jar ,addedOrder=43}
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.util.file.Files] Failed to delete dir: C:\java\jboss\server\default\tmp\deploy\tmp45781edx_rpa.jar
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.deployment.DeploymentInfo] Could not delete file:/C:/java/jboss/server/default/tmp/deploy/tmp45781edx_rpa.jar restart will delete it
> 2005-10-25 17:05:47,370 DEBUG [org.jboss.deployment.MainDeployer] Undeployed file:/C:/java/jboss/server/default/deploy/edx_rpa.jar
> 2005-10-25 17:06:07,385 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:07,385 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:07,385 DEBUG [org.jboss.deployment.MainDeployer] Copying file:/C:/java/jboss/server/default/deploy/ear-rpa.ear -> C:\java\jboss\server\default\tmp\deploy\tmp45787ear-rpa.ear
> 2005-10-25 17:06:08,839 DEBUG [org.jboss.deployment.MainDeployer] using deployer org.jboss.deployment.EARDeployer at cade31
> 2005-10-25 17:06:08,839 INFO  [org.jboss.deployment.EARDeployer] Init J2EE application: file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:08,854 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: META-INF/MANIFEST.MF
> 2005-10-25 17:06:08,854 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: META-INF/application.xml
> 2005-10-25 17:06:08,870 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: ejb-pwc.jar
> 2005-10-25 17:06:08,885 DEBUG [org.jboss.deployment.EARDeployer] Extracted deployable content: ejb-rpatask.jar
> 2005-10-25 17:06:08,885 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/app-classpath.jar
> 2005-10-25 17:06:08,901 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/commons-pool-1.1.jar
> 2005-10-25 17:06:08,901 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_client.jar
> 2005-10-25 17:06:08,948 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_common.jar
> 2005-10-25 17:06:08,948 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_rpa.jar
> 2005-10-25 17:06:08,964 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/edx_system.jar
> 2005-10-25 17:06:10,276 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/jrulesall.jar
> 2005-10-25 17:06:10,464 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/log4j-1.2.11.jar
> 2005-10-25 17:06:10,464 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/logging.jar
> 2005-10-25 17:06:10,479 DEBUG [org.jboss.deployment.EARDeployer] Extracted non-deployable content: lib/sam.jar
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.EARDeployer] Extracted deployable content: war-rpa.war
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.EARDeployer] Deployment Info: org.jboss.deployment.DeploymentInfo at 5a81f787 { url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/war-rpa.war }
>   deployer: null
>   status: null
>   state: CONSTRUCTED
>   watch: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/war-rpa.war
>   altDD: null
>   lastDeployed: 0
>   lastModified: 0
>   mbeans:
> , isDirectory: false
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.EARDeployer] Deployment Info: org.jboss.deployment.DeploymentInfo at afbc8eb4 { url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar }
>   deployer: null
>   status: null
>   state: CONSTRUCTED
>   watch: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
>   altDD: null
>   lastDeployed: 0
>   lastModified: 0
>   mbeans:
> , isDirectory: false
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.deployment.DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repositoryName: JMImplementation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null, repositoryConfig: null)
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 10e790c, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=0}
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.UnifiedLoaderRepository3 at 10e790c, cl=org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=0}
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=0}
> 2005-10-25 17:06:10,510 DEBUG [org.jboss.mx.loading.ClassLoaderUtils] Multiple class loaders found for pkg: 
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] resolveLibraries: lib/app-classpath.jar
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] new manifest entry for sdi at ear-rpa.ear entry is lib/app-classpath.jar
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] The manifest entry in file:/C:/java/jboss/server/default/deploy/ear-rpa.ear references URL file:/C:/java/jboss/server/default/deploy/lib/app-classpath.jar which could not be opened, entry ignored
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.parentTraceEnabled=true
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.nestedTraceEnabled=false
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.util.NestedThrowable] org.jboss.util.NestedThrowable.detectDuplicateNesting=true
> org.jboss.deployment.DeploymentException: url file:/C:/java/jboss/server/default/deploy/lib/app-classpath.jar could not be opened, does it exist?
> 	at org.jboss.deployment.DeploymentInfo.<init>(DeploymentInfo.java:191)
> 	at org.jboss.deployment.MainDeployer.parseManifestLibraries(MainDeployer.java:1101)
> 	at org.jboss.deployment.MainDeployer.init(MainDeployer.java:855)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:780)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> 	at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> 	at $Proxy9.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] found 2 subpackages of file:/C:/java/jboss/server/default/deploy/ear-rpa.ear
> 2005-10-25 17:06:10,948 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
> 2005-10-25 17:06:11,104 DEBUG [org.jboss.deployment.MainDeployer] using deployer MBeanProxyExt[jboss.ejb:service=EJBDeployer]
> 2005-10-25 17:06:11,104 DEBUG [org.jboss.ejb.EJBDeployer] init, ejb-rpatask.jar
> 2005-10-25 17:06:11,120 DEBUG [org.jboss.ejb.EJBDeployer] looking for nested deployments in : file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
> 2005-10-25 17:06:11,120 DEBUG [org.jboss.webservice.ServiceDeployer] handleNotification: org.jboss.deployment.SubDeployer.init,ejb-rpatask.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] Added url: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar, to ucl: org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=51}
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] resolveLibraries: lib/app-classpath.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] new manifest entry for sdi at ejb-rpatask.jar entry is lib/app-classpath.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] No deployer found for url: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/lib/app-classpath.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] Added url: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/lib/app-classpath.jar, to ucl: org.jboss.mx.loading.UnifiedClassLoader3 at 10dc89e{ url=file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear ,addedOrder=51}
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] found 0 subpackages of file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/ejb-rpatask.jar
> 2005-10-25 17:06:11,135 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/C:/java/jboss/server/default/tmp/deploy/tmp45787ear-rpa.ear-contents/war-rpa.war

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 05:19:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 05:19:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3497) (21) test under
 org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException
 (jrockit)
In-Reply-To: <3943595.1155053113119.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20706007.1157966371303.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3497?page=all ]

Dimitris Andreadis closed JBAS-3497.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Alexey Loubyansky)

The execution order of tests in this test case is important so it must be defined explicitly when running under some JVMs

> (21) test under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException (jrockit)
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3497
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3497
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux - dev03 in qa, java: Jrockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> 21 tests under org.jboss.test.cmp2.lob fail with javax.ejb.ObjectNotFoundException. Here is the complete error log:
> No such entity!
> javax.ejb.ObjectNotFoundException: No such entity!
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntityCommand.execute(JDBCFindEntityCommand.java:64)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntity(JDBCStoreManager.java:604)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.findEntity(CMPPersistenceManager.java:315)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer.java:1099)
> 	at org.jboss.ejb.EntityContainer.find(EntityContainer.java:728)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 05:31:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 05:31:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3496) all tests under
 org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
In-Reply-To: <29133751.1155052872676.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30026405.1157967098747.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3496?page=all ]

Dimitris Andreadis closed JBAS-3496.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Alexey Loubyansky)

> all tests under org.jboss.test.cmp2.cmrtree.test fail with javax.ejb.DuplicateKeyException
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3496
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3496
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>         Environment: linux -dev03 in qa, JRockit 1.4.2.11
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> This error does not happen with Sun JDK1.4.
> All test cases under org.jboss.test.cmp2.cmrtree.test have following error:
> Entity with primary key [.1.A.] already exists
> javax.ejb.DuplicateKeyException: Entity with primary key [.1.A.] already exists
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCInsertPKCreateCommand.beforeInsert(JDBCInsertPKCreateCommand.java:99)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractCreateCommand.execute(JDBCAbstractCreateCommand.java:150)
> 	at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.createEntity(JDBCStoreManager.java:587)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.createEntity(CMPPersistenceManager.java:237)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.createEntity(CachedConnectionInterceptor.java:225)
> 	at org.jboss.ejb.EntityContainer.createLocalHome(EntityContainer.java:625)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
> 	at org.jboss.ejb.EntityContainer$ContainerInterceptor.invokeHome(EntityContainer.java:1126)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invokeHome(EntitySynchronizationInterceptor.java:203)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invokeHome(CachedConnectionInterceptor.java:189)
> 	at org.jboss.ejb.plugins.AbstractInterceptor.invokeHome(AbstractInterceptor.java:105)
> 	at org.jboss.ejb.plugins.EntityInstanceInterceptor.invokeHome(EntityInstanceInterceptor.java:134)
> 	at org.jboss.ejb.plugins.EntityLockInterceptor.invokeHome(EntityLockInterceptor.java:76)
> 	at org.jboss.ejb.plugins.EntityCreationInterceptor.invokeHome(EntityCreationInterceptor.java:43)
> 	at org.jboss.ejb.plugins.CallValidationInterceptor.invokeHome(CallValidationInterceptor.java:56)
> 	at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:125)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
> 	at org.jboss.ejb.plugins.TxInterceptorCMT.invokeHome(TxInterceptorCMT.java:161)
> 	at org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.java:145)
> 	at org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:132)
> 	at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invokeHome(ProxyFactoryFinderInterceptor.java:107)
> 	at org.jboss.ejb.EntityContainer.internalInvokeHome(EntityContainer.java:521)
> 	at org.jboss.ejb.Container.invoke(Container.java:975)
> 	at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:359)
> 	at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
> 	at $Proxy204.create(ILjava.lang.String;Ljava.lang.String;)Lorg.jboss.test.cmp2.cmrtree.ejb.ALocal;(Unknown 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

        


From jira-events at jboss.com  Mon Sep 11 06:01:31 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 11 Sep 2006 06:01:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-482) ACTIVATION-GROUP
 not processed by ActionType
In-Reply-To: <16529337.1157936923871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24315265.1157968891569.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-482?page=all ]

Michael Neale resolved JBRULES-482.
-----------------------------------

    Resolution: Done
      Assignee: Michael Neale  (was: Mark Proctor)

fixed in trunk only (will only port to 3.0.x on request as there is a documented workaround). 


> ACTIVATION-GROUP not processed by ActionType
> --------------------------------------------
>
>                 Key: JBRULES-482
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-482
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Steven Williams
>         Assigned To: Michael Neale
>
> The code in ActionType has the following:
>  
> else if ( value.toUpperCase().startsWith( "X" ) || value.toUpperCase().equals( "ACTIVATION-GROUP" ) )
> but above this is a check for startsWith("A") to catch Actions which will always take precedence. Maybe it would be better to check for the full names first and then for the single letter option.
> In the documentation it actually specifies that "XOR-GROUP" should be used, so the other option may be to just remove the "ACTIVATION-GROUP" check, however the current code means new options (such as agenda group for instance) would have to use letters that don't really make sense.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:05:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 06:05:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3492) Test Failure with
 JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
In-Reply-To: <31141571.1155047232621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33373761.1157969131285.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3492?page=all ]

Dimitris Andreadis closed JBAS-3492.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Alexey Loubyansky)

Fixed

> Test Failure with JRockit: org.jboss.test.exception.EntityExceptionUnitTestCase
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3492
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3492
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, CMP service
>         Environment: linux - dev03 in qa lab, JRockit - java version "1.4.2_11"
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> Six tests under org.jboss.test.exception.EntityExceptionUnitTestCase. All fail with the following error
> Error, bean instance was discarded!
> javax.ejb.FinderException: Error, bean instance was discarded!
> 	at org.jboss.test.exception.EntityExceptionTesterBean.ejbFindByPrimaryKey(EntityExceptionTesterBean.java:59)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.callFinderMethod(BMPPersistenceManager.java:632)
> 	at org.jboss.ejb.plugins.BMPPersistenceManager.findEntity(BMPPersistenceManager.java:316)
> 	at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntity(CachedConnectionInterceptor.java:236)
> 	at org.jboss.ejb.EntityContainer.findSingleObject(EntityContainer
> On the server log, I see following for the first error in test suite.
> 2006-08-08 10:09:46,581 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/home/pjha/qa/405CR1/jboss405CR1/testsuite/output/lib/exception.jar
> 2006-08-08 10:09:47,003 DEBUG [org.jboss.ejb.StatelessSessionContainer] Useless invocation of remove() for stateless session bean
> 2006-08-08 10:09:47,150 ERROR [org.jboss.ejb.plugins.LogInterceptor] RuntimeException in method: public abstract void org.jboss.test.exception.EntityExcepti\
> onTesterLocal.runtimeExceptionNoTx():
> java.lang.RuntimeException: Runtime exception without a transaction
>         at org.jboss.test.exception.EntityExceptionTesterBean.runtimeExceptionNoTx(EntityExceptionTesterBean.java:168)
>         at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
>         at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;I)Ljava.lang.Object;(Unknown Source)
>         at org.jboss.invocation.Invocation.performCall(Invocation.java:359)
>         at org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityContainer.java:1187)
>         at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:338)
>         at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
>         at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:126)
>         at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:276)
>         at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:104)
>         at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:68)
>         at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
>         at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:315)
>         at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
>         at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:168)
>         at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
>         at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
>         at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:527)
>         at org.jboss.ejb.Container.invoke(Container.java:954)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:17:32 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Mon, 11 Sep 2006 06:17:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-761) Make connecting
 the channel and state transfer an atomic part of startup
In-Reply-To: <22897707.1157764587331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19526777.1157969852830.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-761?page=all ]

Manik Surtani updated JBCACHE-761:
----------------------------------

        Fix Version/s: 1.4.0.SP2
                       2.0.0
    Affects Version/s: 1.4.0.SP1
                       1.3.0.SP3

> Make connecting the channel and state transfer an atomic part of startup
> ------------------------------------------------------------------------
>
>                 Key: JBCACHE-761
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-761
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 1.4.0.SP2, 2.0.0
>
>
> If an exception is thrown during initial state transfer, the channel should be disconnected.  The exception will propagate out of startService(), which in the AS will leave the cache service in an incompletely deployed state.  But the current code leaves the channel connected, leaving a "zombie" member of the group.
> Probably need to alter stopService() as well to ensure it can handle an already disconnected channel.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:35:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 06:35:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29390677.1157970929905.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3494?page=comments#action_12343125 ] 
            
Dimitris Andreadis commented on JBAS-3494:
------------------------------------------

Not an ordering issue because it is explicilty defined in this testcase.

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, ClassLoading
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:39:36 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 11 Sep 2006 06:39:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-121) Check recovery
In-Reply-To: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33537487.1157971176935.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-121?page=all ]

Mark Little updated JBTM-121:
-----------------------------

    Component/s: WS-T Implementation

> Check recovery
> --------------
>
>                 Key: JBTM-121
>                 URL: http://jira.jboss.com/jira/browse/JBTM-121
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 06:57:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 06:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3580) Error in
 org.jboss.test.jbossmq.test.UnackedUnitTestCase
In-Reply-To: <7836020.1156800287434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30386667.1157972249107.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3580?page=all ]

Dimitris Andreadis closed JBAS-3580.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Adrian Brock)

Fixed ordering

> Error in org.jboss.test.jbossmq.test.UnackedUnitTestCase
> --------------------------------------------------------
>
>                 Key: JBAS-3580
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3580
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testDummyLast - Error
> No durable subscription found for subscription: test
> javax.jms.InvalidDestinationException: No durable subscription found for subscription: test
> 	at org.jboss.mq.sm.AbstractStateManager.getDurableTopic(AbstractStateManager.java:164)
> 	at org.jboss.mq.server.JMSDestinationManager.getDurableTopic(JMSDestinationManager.java:777)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.getDurableTopic(JMSServerInterceptorSupport.java:181)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.destroySubscription(ServerSecurityInterceptor.java:207)
> 	at org.jboss.mq.server.TracingInterceptor.destroySubscription(TracingInterceptor.java:548)
> 	at org.jboss.mq.server.JMSServerInvoker.destroySubscription(JMSServerInvoker.java:162)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:214)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:395)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:398)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Unknown 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

        


From jira-events at jboss.com  Mon Sep 11 07:07:27 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Mon, 11 Sep 2006 07:07:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-136) Define a set of EPRs
 for the Email, Ftp and Database.
Message-ID: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define a set of EPRs for the Email, Ftp and Database.
-----------------------------------------------------

                 Key: JBESB-136
                 URL: http://jira.jboss.com/jira/browse/JBESB-136
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
            Reporter: Arvinder Singh
         Assigned To: Arvinder Singh
             Fix For: 4.0


Define a set of EPRs for the Email, Ftp and Database.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 07:09:27 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Mon, 11 Sep 2006 07:09:27 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-136) Define a set of EPRs
 for Email, Ftp and Database.
In-Reply-To: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27694361.1157972967580.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-136?page=all ]

Arvinder Singh updated JBESB-136:
---------------------------------

    Description: Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format  (was: Define a set of EPRs for the Email, Ftp and Database.)
        Summary: Define a set of EPRs for Email, Ftp and Database.  (was: Define a set of EPRs for the Email, Ftp and Database.)

> Define a set of EPRs for Email, Ftp and Database.
> -------------------------------------------------
>
>                 Key: JBESB-136
>                 URL: http://jira.jboss.com/jira/browse/JBESB-136
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Arvinder Singh
>         Assigned To: Arvinder Singh
>             Fix For: 4.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 07:57:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 11 Sep 2006 07:57:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3603) 6 failing tests
 org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
In-Reply-To: <27907332.1157134303929.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <427701.1157975849629.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3603?page=all ]

Dimitris Andreadis closed JBAS-3603.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Weston Price)

Fixed the ordering of the tests

> 6 failing tests org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------------
>
>                 Key: JBAS-3603
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3603
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> All but one org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase tests fail with
> Transaction already active, cannot nest transactions.
> javax.transaction.NotSupportedException: Transaction already active, cannot nest transactions.
> 	at org.jboss.tm.TxManager.begin(TxManager.java:209)
> 	at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testBrokenConnectionAndTrackByTx(XATxConnectionManagerUnitTestCase.java:290)
> OR
> Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> org.jboss.resource.JBossResourceException: Could not enlist in transaction on entering meta-aware object!; - nested throwable: (javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1])
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:329)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:518)
> 	at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:399)
> 	at org.jboss.test.jca.test.XATxConnectionManagerUnitTestCase.testGetConnection(XATxConnectionManagerUnitTestCase.java:110)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> Caused by: javax.transaction.SystemException: java.lang.Throwable: Unabled to enlist resource, see the previous warnings. tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=build01.dmz.inap.jboss.com/1, BranchQual=, localId=1]
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener$TransactionSynchronization.checkEnlisted(TxConnectionManager.java:728)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:561)
> 	at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:323)
> 	... 16 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 08:35:31 2006
From: jira-events at jboss.com (Morten Hauch (JIRA))
Date: Mon, 11 Sep 2006 08:35:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
Message-ID: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ability for an administrator to add/remove users
------------------------------------------------

                 Key: JBPORTAL-1029
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
            Reporter: Morten Hauch
         Assigned To: Julien Viet


In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 08:35:31 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Mon, 11 Sep 2006 08:35:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-21) Registry service
	interface
Message-ID: <5492093.1157978131897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-21?page=all ]

Kurt Stam reassigned JBESB-21:
------------------------------

    Assignee: Kurt Stam  (was: Mugdho)

> Registry service interface
> --------------------------
>
>                 Key: JBESB-21
>                 URL: http://jira.jboss.com/jira/browse/JBESB-21
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Registry
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Critical
>             Fix For: 4.0
>
>
> We need a registry. It cannot be WS specific, but JAX-R looks like it still matches. Check out what is available in JBossWS (or elsewhere). Assuming we go the JAX-R route (discuss on forum please), then we need stand-alone JAX-R support and a plugin.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 09:01:29 2006
From: jira-events at jboss.com (Morten Hauch (JIRA))
Date: Mon, 11 Sep 2006 09:01:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25059292.1157979689869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Morten Hauch updated JBPORTAL-1029:
-----------------------------------

    Attachment: userportlet.zip

This zip contains the files needed to solve this issue.
See readme.txt for details.

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>            Reporter: Morten Hauch
>         Assigned To: Julien Viet
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:12:32 2006
From: jira-events at jboss.com (Sangeetha Pisharody (JIRA))
Date: Mon, 11 Sep 2006 10:12:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3639) Lookup fails during
	failover
Message-ID: <8989834.1157983952060.JavaMail.jira@cloud.prod.atl2.jboss.com>

Lookup fails during failover
----------------------------

                 Key: JBAS-3639
                 URL: http://jira.jboss.com/jira/browse/JBAS-3639
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-4.0.4RC1, JBossAS-3.2.6 Final
         Environment: jboss 3.2.6
OS: SUSE LINUX 10
            Reporter: Sangeetha Pisharody
         Assigned To: Brian Stansberry


I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup

Properties p = System.getProperties();
p.put(Context.PROVIDER_URL, "localhost:1100");
Context jndiContext = new InitialContext(p);
jndiContext.lookup("XAConnectionFactory");

I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw

javax.naming.NameNotFoundException: XAConnectionFactory
at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
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:324)
at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
at $Proxy42.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
at javax.naming.InitialContext.lookup(InitialContext.java:347)
at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
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:324)
at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
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:324)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
at java.lang.Thread.run(Thread.java:534)

This happened on our test cluster.

On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
Services that lookup XAConnectionFactory threw a similar exception.

I tested with jboss 4.0.4 and the problem still exists

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:27:43 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Mon, 11 Sep 2006 10:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-597) Allow access to
 underlying stream in marshaller with socket transport
Message-ID: <11807485.1157984863851.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow access to underlying stream in marshaller with socket transport
---------------------------------------------------------------------

                 Key: JBREM-597
                 URL: http://jira.jboss.com/jira/browse/JBREM-597
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Tim Fox
         Assigned To: Tom  Elrod
             Fix For: 2.2.0.Beta1 (Bluto)


Currently the ClientSocketWrapper::createOuputStream always returns an ObjectOutputStream wrapping the underlying socket ouput stream.

This ends up getting passed into the marshaller.

With messaging we'd like to use the underlying socket output stream directly in the marshaller - i.e. we don't want to have to write through an object output stream.

This is because the object output stream adds some overhead in terms of the amount of stuff written to the underlying stream..

A similar reasoning applies to InputStream too.

Any chance of changing the socket transport to pass in the underlying socket stream, not an object output/input stream?

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:35:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 10:35:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1030) Add support for
 utility region in existing renderers
Message-ID: <2242969.1157985343870.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for utility region in existing renderers
----------------------------------------------------

                 Key: JBPORTAL-1030
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1030
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:37:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 11 Sep 2006 10:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-296) List and document
 system properties used in JGroups
In-Reply-To: <778373.1157204983788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17969213.1157985463778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-296?page=all ]

Bela Ban resolved JGRP-296.
---------------------------

    Resolution: Done

done

> List and document system properties used in JGroups
> ---------------------------------------------------
>
>                 Key: JGRP-296
>                 URL: http://jira.jboss.com/jira/browse/JGRP-296
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> - bind.address
> - ignore.bind.address
> - jboss.tcpping.initial_hosts
> - jboss.partition.udpPort
> - jboss.partition.udpGroup
> - jboss.mcast.ip.ttl
> #1 Collect all system properties used by JGroups
> #2 Agree on standardized names (e.g. jboss.partition.udpPort --> jgroups.udp.mcast_port)
> #3 Document all properties used by JGroups
> #4 Implement support for both new and old system properties: try to get the value for the new one first (e.g. jgroups.bind_addr), then - if not found - the old one (bind.address). In this case, it probably makes sense to create a function in Util which does this, plus also takes jgroups.ignore.bind_addr into account

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 10:51:43 2006
From: jira-events at jboss.com (Hany Mesha (JIRA))
Date: Mon, 11 Sep 2006 10:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-762) Configuration
 object enhancements
In-Reply-To: <17732187.1157804023738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10629376.1157986303881.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-762?page=all ]

Hany Mesha reassigned JBCACHE-762:
----------------------------------

    Assignee: Hany Mesha  (was: Manik Surtani)

> Configuration object enhancements
> ---------------------------------
>
>                 Key: JBCACHE-762
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-762
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Hany Mesha
>             Fix For: 2.0.0
>
>
> 1.  Why isn't there a CacheFactory.createCache() (using the default configuration)
> 2.  I think it would be useful to have a static method in Configuration which returns the default config, so we could do: Cache c=new DefaultCacheFactory().createCache(Configuration.getDefault())
> 3.  Configuration should have a copy() or clone() method, so we can reuse a config, and make small modifications
> 4.  Make Configuration serializable (ship them around ?)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:01:44 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 11 Sep 2006 11:01:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-597) Allow access to
 underlying stream in marshaller with socket transport
In-Reply-To: <11807485.1157984863851.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10526410.1157986904894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-597?page=all ]

Tom  Elrod updated JBREM-597:
-----------------------------

          Component/s: transport
    Affects Version/s: 2.0.0.GA (Boon)
             Priority: Critical  (was: Major)

> Allow access to underlying stream in marshaller with socket transport
> ---------------------------------------------------------------------
>
>                 Key: JBREM-597
>                 URL: http://jira.jboss.com/jira/browse/JBREM-597
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tim Fox
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> Currently the ClientSocketWrapper::createOuputStream always returns an ObjectOutputStream wrapping the underlying socket ouput stream.
> This ends up getting passed into the marshaller.
> With messaging we'd like to use the underlying socket output stream directly in the marshaller - i.e. we don't want to have to write through an object output stream.
> This is because the object output stream adds some overhead in terms of the amount of stuff written to the underlying stream..
> A similar reasoning applies to InputStream too.
> Any chance of changing the socket transport to pass in the underlying socket stream, not an object output/input stream?

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:25:43 2006
From: jira-events at jboss.com (Alex Pinkin (JIRA))
Date: Mon, 11 Sep 2006 11:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1031) Update docs with
 info on the latest installer.
Message-ID: <6977550.1157988343845.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update docs with info on the latest installer.
----------------------------------------------

                 Key: JBPORTAL-1031
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1031
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.4 Final
            Reporter: Alex Pinkin
         Assigned To: Roy Russo
             Fix For: 2.4.1 Final


need to mention that latest installer allows to configure datasource.

http://labs.jboss.com/portal/jemsinstaller/downloads

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:33:43 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 11 Sep 2006 11:33:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-666) Throw
 javax.ejb.ConcurrentAccessException when two threads access the same SFSB
 instance
In-Reply-To: <29278907.1153950371470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19586494.1157988823950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-666?page=all ]

Carlo de Wolf resolved EJBTHREE-666.
------------------------------------

    Resolution: Done

> Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-666
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> See section 4.13.3 of the EJB Core Contracts specification.
> I need this for Seam.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:40:32 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 11 Sep 2006 11:40:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-666) Throw
 javax.ejb.ConcurrentAccessException when two threads access the same SFSB
 instance
In-Reply-To: <29278907.1153950371470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27169561.1157989232268.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-666?page=comments#action_12343138 ] 
            
Gavin King commented on EJBTHREE-666:
-------------------------------------

thanks for the fix :)

> Throw javax.ejb.ConcurrentAccessException when two threads access the same SFSB instance
> ----------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-666
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-666
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> See section 4.13.3 of the EJB Core Contracts specification.
> I need this for Seam.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:48:35 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Mon, 11 Sep 2006 11:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-484) refactor the core
 reteoo code for sinle and composite propagations
Message-ID: <6257948.1157989715700.JavaMail.jira@cloud.prod.atl2.jboss.com>

refactor the core reteoo code  for sinle and composite propagations
-------------------------------------------------------------------

                 Key: JBRULES-484
                 URL: http://jira.jboss.com/jira/browse/JBRULES-484
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1


The profiling shows that much time is spent in iteration loops. So we  should  look  at using Single and Composite Adapters for propagations. Further we should avoid using ArrayLists and instead use our own custom LinkedList or arrays.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 11:48:35 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Mon, 11 Sep 2006 11:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-484) refactor the
 core reteoo code for sinle and composite propagations
In-Reply-To: <6257948.1157989715700.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16650160.1157989715853.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-484?page=comments#action_12343139 ] 
            
Mark Proctor commented on JBRULES-484:
--------------------------------------

This jira also includes the refactored alpha node hashing.

> refactor the core reteoo code  for sinle and composite propagations
> -------------------------------------------------------------------
>
>                 Key: JBRULES-484
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-484
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Reteoo
>            Reporter: Mark Proctor
>         Assigned To: Mark Proctor
>             Fix For: 3.1-m1
>
>
> The profiling shows that much time is spent in iteration loops. So we  should  look  at using Single and Composite Adapters for propagations. Further we should avoid using ArrayLists and instead use our own custom LinkedList or arrays.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 12:32:32 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Mon, 11 Sep 2006 12:32:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4487714.1157992352984.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Nitzan Niv updated JBCACHE-760:
-------------------------------

    Attachment: CollectionClassHandler.java
                TreeCacheAopListenerTest.java

Attached is a modified CollectionClassHandler that resolves this issue and a modified TestCase that checks it.

The problem is in collectionObjectPut() and it is resolved by putting an initialized AOPInstance in the FQN before putting the collection's Class there.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 12:38:35 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Mon, 11 Sep 2006 12:38:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10227838.1157992715257.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Manik Surtani reassigned JBCACHE-760:
-------------------------------------

    Assignee: Ben Wang  (was: Manik Surtani)

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:09:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 11 Sep 2006 13:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-311) Use JAVA_HOME in path
 to java executable
Message-ID: <18417266.1157994583822.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use JAVA_HOME in path to java executable
----------------------------------------

                 Key: JGRP-311
                 URL: http://jira.jboss.com/jira/browse/JGRP-311
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1, 2.3, 2.2.9 SP3 (2.2.9.3), 2.2.9.2, 2.2.9.1, 2.2.9, 2.2.8
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: 2.4


In build.bat and build.sh, JAVA_HOME is used in building the classpath but not in creating the path to the java executable that's launched.  That leads to JVM version problems for odd people like me whose JAVA_HOME points to a different JDK than the system's default JDK.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:11:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 11 Sep 2006 13:11:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JGRP-311) Use JAVA_HOME in path
 to java executable
In-Reply-To: <18417266.1157994583822.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23954867.1157994703808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-311?page=all ]

Brian Stansberry closed JGRP-311.
---------------------------------

    Resolution: Done

> Use JAVA_HOME in path to java executable
> ----------------------------------------
>
>                 Key: JGRP-311
>                 URL: http://jira.jboss.com/jira/browse/JGRP-311
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.8, 2.2.9, 2.3, 2.2.9.1, 2.2.9.2, 2.2.9 SP3 (2.2.9.3), 2.3 SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.4
>
>
> In build.bat and build.sh, JAVA_HOME is used in building the classpath but not in creating the path to the java executable that's launched.  That leads to JVM version problems for odd people like me whose JAVA_HOME points to a different JDK than the system's default JDK.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:13:44 2006
From: jira-events at jboss.com (Mauro Lopez (JIRA))
Date: Mon, 11 Sep 2006 13:13:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-344) Portal booking
 example loses conversation after validation error
In-Reply-To: <3224811.1157572229321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4347164.1157994824484.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-344?page=comments#action_12343148 ] 
            
Mauro Lopez commented on JBSEAM-344:
------------------------------------

Reproduced also with latest jems installer (jems-installer-1.2.0.BETA2), which bundles JBoss Portal 2.4.0-GA

> Portal booking example loses conversation after validation error
> ----------------------------------------------------------------
>
>                 Key: JBSEAM-344
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-344
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Portal
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4.GA
> JBoss Portal 2.4.0-Beta1
> (used jems-installer-1.2.0.BETA)
> JBoss Seam 1.0.1.GA
>            Reporter: Mauro Lopez
>
> Followed this steps:
> - deployed the application in examples/portal using ant, as described in examples/portal/readme.txt
> - Entered http://localhost:8080/portal
> - Selected the SeamHibernate portlet tab, registered user, logged in...
> - Searched hotels, selected one of them, and pressed the "Book" button.
> In the Book Hotel screen, if the credit card number hasn't got 16 digits, a message is shown. After that, having entered 16 digits for the credit card, instead of the confirm screen, the "Search Hotels" screen is shown, with the message "No conversation". 
> So, after a failed validation, the conversation is lost.
> In my own examples I've substituted conversational scope with session scope, just to see them working. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 13:19:43 2006
From: jira-events at jboss.com (Kerry Barnes (JIRA))
Date: Mon, 11 Sep 2006 13:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3640) Clustering of the
 quartz-ra.rar failes
Message-ID: <21839615.1157995183907.JavaMail.jira@cloud.prod.atl2.jboss.com>

Clustering of the quartz-ra.rar failes
--------------------------------------

                 Key: JBAS-3640
                 URL: http://jira.jboss.com/jira/browse/JBAS-3640
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Clustered JBoss where the Quartz-ra.rar is set up for clustering by using any JDBC DataStore
            Reporter: Kerry Barnes
         Assigned To: Weston Price


When using a JDBC Data Store for the Quarts-ra.rar, the rar fails by indicating that you cannot have a non-volatile trigger associated with a volatile job.

The JobStoreCMT file checks to make sure that if the JobDetail is marked as "volatile" the corresponding Trigger is also marked as "volatile." But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to "true" during construction, but the CronTrigger doesn't supply that option at construction and the default setting is to have the volatility set to "false," which is never changed. A mismatch and a problem

The easiest solution is to modify the JobDetail construction volatility parameter to false so that both instances match. In my tests this generates the desired effect.


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:51:43 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-485) Add "collect"
 conditional element
Message-ID: <7545731.1158000703819.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add "collect" conditional element
---------------------------------

                 Key: JBRULES-485
                 URL: http://jira.jboss.com/jira/browse/JBRULES-485
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: All
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 3.1-m1


Add "collect" conditional element.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:53:43 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-486) Add core and
 compiler support to "collect" conditional element
Message-ID: <30283539.1158000824009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add core and compiler support to "collect" conditional element
--------------------------------------------------------------

                 Key: JBRULES-486
                 URL: http://jira.jboss.com/jira/browse/JBRULES-486
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 3.1-m1


Add support for "collect" conditional element into core and compiler components.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:53:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:53:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-487) Add eclipse plugin
 support for "collect" conditional element
Message-ID: <4117803.1158000824149.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add eclipse plugin support for "collect" conditional element
------------------------------------------------------------

                 Key: JBRULES-487
                 URL: http://jira.jboss.com/jira/browse/JBRULES-487
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Edson Tirelli
             Fix For: 3.1-m1


Add support for "collect" conditional element into eclipse plugin.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:55:43 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-488) Create
 documentation for "collect" conditional element
Message-ID: <27065514.1158000943841.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create documentation for "collect" conditional element
------------------------------------------------------

                 Key: JBRULES-488
                 URL: http://jira.jboss.com/jira/browse/JBRULES-488
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Edson Tirelli
         Assigned To: Edson Tirelli
             Fix For: 3.1-m1


Add documentation for "collect" conditional element.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 14:55:44 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Mon, 11 Sep 2006 14:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-487) Add eclipse
 plugin support for "collect" conditional element
In-Reply-To: <4117803.1158000824149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21688286.1158000944042.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-487?page=all ]

Edson Tirelli reassigned JBRULES-487:
-------------------------------------

    Assignee: Kris Verlaenen

> Add eclipse plugin support for "collect" conditional element
> ------------------------------------------------------------
>
>                 Key: JBRULES-487
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-487
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Edson Tirelli
>         Assigned To: Kris Verlaenen
>             Fix For: 3.1-m1
>
>
> Add support for "collect" conditional element into eclipse plugin.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:09:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <461376.1158001784057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Roy Russo reassigned JBPORTAL-1029:
-----------------------------------

    Assignee: Roy Russo  (was: Julien Viet)

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final, 2.6.Alpha1
>            Reporter: Morten Hauch
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:09:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 15:09:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2885841.1158001784213.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Roy Russo updated JBPORTAL-1029:
--------------------------------

        Fix Version/s: 2.6.Alpha1
    Affects Version/s: 2.4.1 Final
          Component/s: Portal Core
                           (was: Portal Portlet)
        Fix Version/s: 2.4.1 Final
    Affects Version/s: 2.6.Alpha1

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final, 2.6.Alpha1
>            Reporter: Morten Hauch
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:41:44 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 15:41:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1030) Add support for
 utility region in existing renderers
In-Reply-To: <2242969.1157985343870.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25037607.1158003704248.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1030?page=all ]

Roy Russo resolved JBPORTAL-1030.
---------------------------------

    Resolution: Done

Added support for injection of region content, not bound to window fragments.

> Add support for utility region in existing renderers
> ----------------------------------------------------
>
>                 Key: JBPORTAL-1030
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1030
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:51:43 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 11 Sep 2006 15:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3642) Flag an exception in
 CachedConnectionValve if CachedConnectionManager is unavailable
Message-ID: <14004899.1158004303788.JavaMail.jira@cloud.prod.atl2.jboss.com>

Flag an exception in CachedConnectionValve if CachedConnectionManager is unavailable
------------------------------------------------------------------------------------

                 Key: JBAS-3642
                 URL: http://jira.jboss.com/jira/browse/JBAS-3642
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


If the CachedConnectionManager dependency in the Tomcat service is commented out and the CachedConnectionValve is active, there is a NPE.

It is better to throw an RuntimeException suggesting the user as to what needs to be configured (uncomment the CCM dependeny).

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 15:53:31 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 11 Sep 2006 15:53:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3642) Flag an exception in
 CachedConnectionValve if CachedConnectionManager is unavailable
In-Reply-To: <14004899.1158004303788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21362164.1158004411994.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3642?page=all ]

Anil Saldhana closed JBAS-3642.
-------------------------------

    Resolution: Done

Done.

> Flag an exception in CachedConnectionValve if CachedConnectionManager is unavailable
> ------------------------------------------------------------------------------------
>
>                 Key: JBAS-3642
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3642
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> If the CachedConnectionManager dependency in the Tomcat service is commented out and the CachedConnectionValve is active, there is a NPE.
> It is better to throw an RuntimeException suggesting the user as to what needs to be configured (uncomment the CCM dependeny).

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:03:30 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Mon, 11 Sep 2006 16:03:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31169861.1158005010493.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343157 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

I've completed the first design for the icon based on the new splash screen.

http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm

16 x 16 icon:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside.gif

32 x 32 icon:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside.gif

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:03:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:03:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-625) Embeddable EJB3
 sets up two copies of interceptor declared in ejb-jar.xml
Message-ID: <24984226.1158005010669.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-625?page=all ]

Bill Burke closed EJBTHREE-625.
-------------------------------

    Resolution: Done

> Embeddable EJB3 sets up two copies of interceptor declared in ejb-jar.xml
> -------------------------------------------------------------------------
>
>                 Key: EJBTHREE-625
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-625
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Gavin King
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> My session beans have interceptors attached via:
> <ejb-jar>
>    <assembly-descriptor>
>       <interceptor-binding>
>          <ejb-name>*</ejb-name>
>          <interceptor-class>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
>       </interceptor-binding>
>    </assembly-descriptor>
> </ejb-jar>
> And (only) when running in embeddable EJB3, they get two instances of SeamInterceptor.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:05:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:05:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-588) Refactor EJB3
 MetaModel and create web.xml/jboss-web.xml metamodel
Message-ID: <31176797.1158005130505.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-588?page=all ]

Bill Burke closed EJBTHREE-588.
-------------------------------

    Resolution: Done

> Refactor EJB3 MetaModel and create web.xml/jboss-web.xml metamodel
> ------------------------------------------------------------------
>
>                 Key: EJBTHREE-588
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-588
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: EJB 3.0 RC9 - FD
>
>
> * refactor all the shared DD elements between ejb-jar.xml and web.xml into their own reusable metamodel. 
> * for now, unless Scott changes, put this new metamodel in jboss-head/j2ee under:
>    org.jboss.metamodel
> * Create a metamodel and XML parsing (the jbossxb shit) for web.xml and jboss-web.xml.  Put this under the jboss-head/tomcat module under
> org.jboss.web.metamodel
> If you can think of a better name for these packages, then do that.
> *DO NOT USE THE OLD WEB.XML SCHEMA!*
> Download the Java EE 5 Servlet specification to obtain the new XML schema for Java EE 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

        


From jira-events at jboss.com  Mon Sep 11 16:07:32 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-217) The container
 should Instruments Hibernate classes
Message-ID: <2459966.1158005252761.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-217?page=all ]

Bill Burke updated EJBTHREE-217:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> The container should Instruments Hibernate classes
> --------------------------------------------------
>
>                 Key: EJBTHREE-217
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-217
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 Beta 1
>            Reporter: Emmanuel Bernard
>         Assigned To: Bill Burke
>            Priority: Minor
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Right now, the user has to instrument Hibernate classes itself through a InstrumentAnt task to enable some features such as property level lazy loading
> It'd be cool if the container execute the same job at class load time in an automatic manner.
> http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#performance-fetching-lazyproperties

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:32 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-197) Deploy Hibernate
 MBean statistics in the EJB 3 Deployer
Message-ID: <23787556.1158005252925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-197?page=all ]

Bill Burke updated EJBTHREE-197:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Deploy Hibernate MBean statistics in the EJB 3 Deployer
> -------------------------------------------------------
>
>                 Key: EJBTHREE-197
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-197
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Michael Yuan
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I discussed this with Emmanuel and Steve over email. They both thought it should be fairly easy to add. The JBoss Network team needs this feature to develop profiling and monitoring tools for EJB 3 (see the linked issue).
> Can we have this feature in the JavaOne release of the product? I can demo it in the trail blazer.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-582)
 Refactoring/implementation of ejb3 sfsb clustering
Message-ID: <32875950.1158005253120.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-582?page=all ]

Bill Burke updated EJBTHREE-582:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Refactoring/implementation of ejb3 sfsb clustering
> --------------------------------------------------
>
>                 Key: EJBTHREE-582
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-582
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This is top level task to track all the tasks related to refactoring and implemntation of current ejb3 sfsb clustering support. Current items include:
> 1. Use JBC to handle passivation
> 2. Make sure straight JBC works with more test cases
> 3. implement fine-grained option

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-402) Remoting proxies
 are not declaring serialVersionUIDs
Message-ID: <32458464.1158005253323.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=all ]

Bill Burke updated EJBTHREE-402:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-477) Implement
 @WebServiceRef and <service-ref>
Message-ID: <31658808.1158005253545.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-477?page=all ]

Bill Burke updated EJBTHREE-477:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Implement @WebServiceRef and <service-ref>
> ------------------------------------------
>
>                 Key: EJBTHREE-477
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-477
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This will be fun!!!!
> Take a look at code in EJB 2.1 container.  DO NOT USE THAT CODE DIRECTLY.  I want to start removing dependencies on that code.  You can also work with WS team on this too.  This should be a HIG PRIORITY task.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-466) support
 persistence properties for XML and injection annotations
Message-ID: <32119965.1158005253696.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-466?page=all ]

Bill Burke updated EJBTHREE-466:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> support persistence properties for XML and injection annotations
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-466
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-466
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC5 - PFD
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:33 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-344) Deployment should
 fail for resource injection to both field and method
Message-ID: <17879372.1158005253915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-344?page=all ]

Bill Burke updated EJBTHREE-344:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Deployment should fail for resource injection to both field and method
> ----------------------------------------------------------------------
>
>                 Key: EJBTHREE-344
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-344
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: org.jboss.ejb3.test.naming.unit.BadInjectionsUnitTestCase
>            Reporter: Scott M Stark
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I belive the indicated BadInjectionsUnitTestCase should be failing to deploy due to the attempt to inject an env-entry via both a field and method annotation. The ejb-jar.xml key env-entry value is not being injected via either mechanism it appears.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-420) redeploy of
 TreeCached entities fails
Message-ID: <11523404.1158005254142.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-420?page=all ]

Bill Burke updated EJBTHREE-420:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> redeploy of TreeCached entities fails
> -------------------------------------
>
>                 Key: EJBTHREE-420
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-420
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> 2006-01-20 15:14:19,843 INFO  [STDOUT] org.hibernate.PropertyAccessException: exception getting property value with CGLIB (set hibernate.cglib.use_reflection_optimizer=false for more info) getter of com.airit.fidsdb.entity.ArrPrevPortPK.?
>         at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:79)
>         at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:307)
>         at org.hibernate.type.ComponentType.isEqual(ComponentType.java:111)
>         at org.hibernate.cache.CacheKey.equals(CacheKey.java:51)
>         at org.jboss.cache.Fqn.equals(Fqn.java:134)
>         at java.util.HashMap.eq(HashMap.java:277)
>         at java.util.HashMap.containsKey(HashMap.java:346)
>         at org.jboss.cache.eviction.LRUAlgorithm.add(LRUAlgorithm.java:126)
>         at org.jboss.cache.eviction.LRUAlgorithm.processAddedNodes(LRUAlgorithm.java:99)
>         at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:77)
>         at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:52)
>         at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37)
>         at java.util.TimerThread.mainLoop(Timer.java:512)
>         at java.util.TimerThread.run(Timer.java:462)
> Caused by: java.lang.ClassCastException: com.airit.fidsdb.entity.ArrPrevPortPK
>         at com.airit.fidsdb.entity.ArrPrevPortPK$$BulkBeanByCGLIB$$8b6b36b9.getPropertyValues(<generated>)
>         at net.sf.cglib.beans.BulkBean.getPropertyValues(BulkBean.java:48)
>         at org.hibernate.tuple.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:76)
>         ... 13 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-645) complete
 framework for running standard tests in E-EJB3
Message-ID: <1904401.1158005254276.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-645?page=all ]

Bill Burke updated EJBTHREE-645:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> complete framework for running standard tests in E-EJB3
> -------------------------------------------------------
>
>                 Key: EJBTHREE-645
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-645
>             Project: EJB 3.0
>          Issue Type: Task
>            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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-405) Allow EJB
 Container's ObjectName to be configurable through annotation or XML
Message-ID: <10868811.1158005254717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-405?page=all ]

Bill Burke updated EJBTHREE-405:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Allow EJB Container's ObjectName to be configurable through annotation or XML
> -----------------------------------------------------------------------------
>
>                 Key: EJBTHREE-405
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-405
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-127) Create Docbook
	for @Consumer
Message-ID: <28581077.1158005254915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-127?page=all ]

Bill Burke updated EJBTHREE-127:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Create Docbook for @Consumer
> ----------------------------
>
>                 Key: EJBTHREE-127
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-127
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-525) implement
 <service-ref> in jboss.xml
Message-ID: <4857845.1158005255044.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-525?page=all ]

Bill Burke updated EJBTHREE-525:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> implement <service-ref> in jboss.xml
> ------------------------------------
>
>                 Key: EJBTHREE-525
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-525
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC6 - PFD
>            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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-305) Port EJB 2.1
 tests to EJB 3.0 where appropriate
Message-ID: <5222112.1158005255196.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-305?page=all ]

Bill Burke updated EJBTHREE-305:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Port EJB 2.1 tests to EJB 3.0 where appropriate
> -----------------------------------------------
>
>                 Key: EJBTHREE-305
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-305
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC4 - PFD
>            Reporter: Bill Burke
>         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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-672) Use a combination
 of FD and FD_SOCK in the default JGroups protocol stack.
In-Reply-To: <18847956.1154557031452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30909595.1158005255332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-672?page=all ]

Bill Burke updated EJBTHREE-672:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Use a combination of FD and FD_SOCK in the default JGroups protocol stack.
> --------------------------------------------------------------------------
>
>                 Key: EJBTHREE-672
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-672
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same as JBAS-3004.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-585) ejb3 fine-grained
 sfsb replication support
Message-ID: <31994731.1158005255541.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-585?page=all ]

Bill Burke updated EJBTHREE-585:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> ejb3 fine-grained sfsb replication support
> ------------------------------------------
>
>                 Key: EJBTHREE-585
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-585
>             Project: EJB 3.0
>          Issue Type: Feature Request
>          Components: Clustering
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This is the parent issue to track the overal fine-grained implementation using PojoCache

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-191) servlet
 initialization happens before EJB startup
Message-ID: <22243525.1158005255664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-191?page=all ]

Bill Burke updated EJBTHREE-191:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> servlet initialization happens before EJB startup
> -------------------------------------------------
>
>                 Key: EJBTHREE-191
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-191
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:37 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-141) Stateful session
 PostConstruct missing transaction, security contexts
Message-ID: <11815339.1158005257920.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-141?page=all ]

Bill Burke updated EJBTHREE-141:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Stateful session PostConstruct missing transaction, security contexts
> ---------------------------------------------------------------------
>
>                 Key: EJBTHREE-141
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-141
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>         Environment: jboss-head
>            Reporter: Jeff Schnitzer
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> While PostConstruct for stateless beans does not run in a transaction or security context, stateful beans are different.  From section 5.1.4.1 "Semantics of the Life Cycle Callback Methods for Stateful Session Beans" of the ejb3-edr2 spec:
> "The PostConstruct method is invoked in the transaction context and security contexts of the first business method on the bean."

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-472) problem with mail
Message-ID: <31624332.1158005258096.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-472?page=all ]

Bill Burke updated EJBTHREE-472:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> problem with mail
> -----------------
>
>                 Key: EJBTHREE-472
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-472
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Bill Burke
>         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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-551) Memory leak in
	EJB3
Message-ID: <16805100.1158005258315.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-551?page=all ]

Bill Burke updated EJBTHREE-551:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Memory leak in EJB3
> -------------------
>
>                 Key: EJBTHREE-551
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-551
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Adrian Brock
>             Fix For: EJB 3.0 RC10 - FD
>
>
> See the linked JBossAS Task

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-498) Review duplicate
 security constructs
Message-ID: <28733385.1158005258502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-498?page=all ]

Bill Burke updated EJBTHREE-498:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Review duplicate security constructs
> ------------------------------------
>
>                 Key: EJBTHREE-498
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-498
>             Project: EJB 3.0
>          Issue Type: Task
>          Components: Security
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Both ejb3 and aspects/aop have duplicate implementations of JBossSX security constructs that should belong to that project rather than replicated elsewhere. I need to review these and move them into the security project where approriate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-322) implement
	discarding rules
Message-ID: <21931761.1158005258631.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-322?page=all ]

Bill Burke updated EJBTHREE-322:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> implement discarding rules
> --------------------------
>
>                 Key: EJBTHREE-322
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-322
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC1, EJB 3.0 RC2, EJB 3.0 RC3
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> we are not discarding EJB instances where appropriate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-124)
 @PersistenceContext(EXTENDED) should follow new Spec defined rules
Message-ID: <7897902.1158005258755.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-124?page=all ]

Bill Burke updated EJBTHREE-124:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> @PersistenceContext(EXTENDED) should follow new Spec defined rules
> ------------------------------------------------------------------
>
>                 Key: EJBTHREE-124
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-124
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: Preview 5
>            Reporter: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I don't yet follow all the spec defined rules for @PersistenceContext(EXTENDED)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:38 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-342) Unify
 configuration file names and bootstrap
Message-ID: <11969392.1158005258955.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-342?page=all ]

Bill Burke updated EJBTHREE-342:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Unify configuration file names and bootstrap
> --------------------------------------------
>
>                 Key: EJBTHREE-342
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-342
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: Christian Bauer
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> The microcontainer can be booted with StandaloneBootstrap, and it searches for jboss-beans.xml in / and META-INF.
> The E-EJB3 container is booted with EJB3StandaloneBootstrap, which searches for embedded-jboss-beans.xml in / and supports a "basepath" argument.
> Unify these two bootstrap classes. Wishlist:
> - sensible default name for the configuration file ("jboss-beans.xml" sounds good)
> - searches in default locations (/ and META-INF)
> - supports parameters to completely override not only the "basepath", but the full location of the configuration file
> The EJB3StandaloneBootstrap should _extend_ the StandaloneBootstrap, not reimplement it. The current situation makes documentation and explanation unecessarily difficult.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:39 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-564) Inconsistent
 results in ConsumerUnitTestCase
Message-ID: <18256075.1158005259208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-564?page=all ]

Bill Burke updated EJBTHREE-564:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Inconsistent results in ConsumerUnitTestCase
> --------------------------------------------
>
>                 Key: EJBTHREE-564
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-564
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>            Reporter: Scott M Stark
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC10 - FD
>
>
> If I run the ConsumerUnitTestCase multiple times I start seeing failures due to method invocation order it seems.
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>     [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 16.344 sec
> BUILD SUCCESSFUL
> Total time: 21 seconds
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>     [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 14.359 sec
>     [junit] Test org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase FAILED
> BUILD SUCCESSFUL
> Total time: 19 seconds
> [starksm at banshee9100 ejb3]$ ant -buildfile build-test.xml -Dtest=consumer test
> Buildfile: build-test.xml
> init:
> test:
> test-with-jvmargs:
>    [delete] Deleting: C:\cvs\JBoss4.0\jboss-4.0.x\ejb3\output\log\test.log
>     [junit] Running org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase
>     [junit] Tests run: 6, Failures: 1, Errors: 0, Time elapsed: 14.86 sec
>     [junit] Test org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase FAILED
> BUILD SUCCESSFUL
> Total time: 19 seconds
>   <testcase classname="org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase" name="testDeploymentDescriptorQueueXA" time="2.032">
>     <failure message="expected:&lt;...1&gt; but was:&lt;...2&gt;" type="junit.framework.ComparisonFailure">junit.framework.ComparisonFailure: expected:&lt;...1&gt; but was:&lt;...2&gt;
> 	at org.jboss.ejb3.test.consumer.unit.ConsumerUnitTestCase.testDeploymentDescriptorQueueXA(ConsumerUnitTestCase.java:151)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> </failure>

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:40 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-372) MDB Management
	features
Message-ID: <20023022.1158005260029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-372?page=all ]

Bill Burke updated EJBTHREE-372:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> MDB Management features
> -----------------------
>
>                 Key: EJBTHREE-372
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-372
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Kabir Khan
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Implement startDelivery(), stopDelivery(), setMaxMessages(int) and adjust the MDB pool size for MDBs

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:40 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-575) Access
 configuration attributes through JMX
Message-ID: <1429039.1158005260152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-575?page=all ]

Bill Burke updated EJBTHREE-575:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Access configuration attributes through JMX
> -------------------------------------------
>
>                 Key: EJBTHREE-575
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-575
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Darran Lofthouse
>             Fix For: EJB 3.0 RC10 - FD
>
>
> This might be more appropriate split into a number of tasks but for the moment I am raising it as a single issue.
> There are a number of properties that can be set on message driven beans using activation config properties e.g. 'maxPoolSize'.  After deployment there is not a mechanism to check that the correct properties have been applied.  It would be good to be able to inspect the configuration values using JMX.
> Using the @PoolClass annotation it is possible to configure the pool that is used for the EJB, it would also be good if this configuration information could also be made available using JMX.
> For the configuration items it would also be good if the attributes could be updated using JMX.
> Finally providing status information such as current pool sizes through JMX would also help users check the configuration they have selected is appropriate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:40 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-27) Allowed methods
Message-ID: <31773060.1158005260850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-27?page=all ]

Bill Burke updated EJBTHREE-27:
-------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Allowed methods
> ---------------
>
>                 Key: EJBTHREE-27
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-27
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: Preview 5
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC10 - FD
>
>
> EJB specification has semanatics for what methods can be called when.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:07:41 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-421) Put
 FlushMode.NEVER back on
 track through @FlushMode, at least in a proprietary manner
Message-ID: <22367258.1158005261038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-421?page=all ]

Bill Burke updated EJBTHREE-421:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Put FlushMode.NEVER back on track through @FlushMode, at least in a proprietary manner
> --------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-421
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-421
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Emmanuel Bernard
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:41 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-414) Support Nested
 SFSB in clustered environment
Message-ID: <651104.1158005261288.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-414?page=all ]

Bill Burke updated EJBTHREE-414:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> Support Nested SFSB in clustered environment
> --------------------------------------------
>
>                 Key: EJBTHREE-414
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-414
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:07:41 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-12) EJB ENC must be
 java:comp/env currently it is java.ejb/comp/env
Message-ID: <6915320.1158005261503.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-12?page=all ]

Bill Burke updated EJBTHREE-12:
-------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> EJB ENC must be java:comp/env  currently it is java.ejb/comp/env
> ----------------------------------------------------------------
>
>                 Key: EJBTHREE-12
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-12
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: Preview 5
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             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

        


From jira-events at jboss.com  Mon Sep 11 16:09:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-212) Support
	servlet/jsp injection
Message-ID: <26962743.1158005370570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke closed EJBTHREE-212.
-------------------------------

    Resolution: Done

This works ONLY in HEAD.  JSP injection not working yet.  Requires some changes to Tomcat.

> Support servlet/jsp injection
> -----------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:09:30 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-212) Support
	servlet/jsp injection
Message-ID: <30166601.1158005370862.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke reopened EJBTHREE-212:
---------------------------------

             

> Support servlet/jsp injection
> -----------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:09:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-212) Support servlet
	injection
Message-ID: <3097357.1158005371144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke updated EJBTHREE-212:
--------------------------------

    Summary: Support servlet injection  (was: Support servlet/jsp injection)

create JSP task in different task

> Support servlet injection
> -------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:09:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:09:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-212) Support servlet
	injection
Message-ID: <10627374.1158005371427.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-212?page=all ]

Bill Burke closed EJBTHREE-212.
-------------------------------

    Resolution: Done

> Support servlet injection
> -------------------------
>
>                 Key: EJBTHREE-212
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-212
>             Project: EJB 3.0
>          Issue Type: Feature Request
>    Affects Versions: EJB 3.0 RC2
>            Reporter: Bill Burke
>         Assigned To: Bill Burke
>             Fix For: EJB 3.0 RC9 - FD
>
>
> I believe this can be done using JBoss AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:11:29 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:11:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-687)
	EntityManager.getDelegate()
In-Reply-To: <15751408.1155655220332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19246799.1158005489946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-687?page=all ]

Bill Burke updated EJBTHREE-687:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> EntityManager.getDelegate()
> ---------------------------
>
>                 Key: EJBTHREE-687
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-687
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Emmanuel Bernard
>             Fix For: EJB 3.0 RC10 - FD
>
>
> EntityManager.getdelegate() currently returns the underlying entityManager (let's say HibernateEntityManager)
> It is more convinient and coherence between SE and EE to return hibernateEntityManager.getDelegate() rather than hibernate EntityManager

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:13:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-509) EJB 3.0
 persistense manager
 unit name is not comming up when deploying entity bean
Message-ID: <21911233.1158005611705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-509?page=all ]

Bill Burke updated EJBTHREE-509:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> EJB 3.0 persistense manager unit name is not comming up when deploying entity bean
> ----------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-509
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-509
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC5 - PFD
>         Environment: linux, jboss 4.0.2
>            Reporter: Amit Chauhan
>            Priority: Minor
>             Fix For: EJB 3.0 RC10 - FD
>
>
> trying to implement the tutorial example provided at http://docs.jboss.org/ejb3/app-servers/tutorials/entity/entity.html

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:13:31 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Mon, 11 Sep 2006 16:13:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-661) Security:
 Deploying a bean
 without mandatory org.jboss.ejb3.security.SecurityDomain results in a
 NullPointerException
In-Reply-To: <7251726.1153836311374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2340557.1158005611835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-661?page=all ]

Bill Burke updated EJBTHREE-661:
--------------------------------

    Fix Version/s:     (was: EJB 3.0 RC9 - FD)
                   EJB 3.0 RC10 - FD

> Security: Deploying a bean without mandatory org.jboss.ejb3.security.SecurityDomain results in a NullPointerException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-661
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-661
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>             Fix For: EJB 3.0 RC10 - FD
>
>
> When setting up security in a EJB3 bean, it is mandatory adding the 
> org.jboss.ejb3.security.SecurityDomain tag. Failure to do so results 
> on a NullPointerException. 
> AS should log a more meaningful message rather than a 
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 16:21:30 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Mon, 11 Sep 2006 16:21:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-658) @Resources at
 class level does not create correct local jndi binding
In-Reply-To: <29222280.1153431671371.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21627034.1158006090850.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-658?page=all ]

William DeCoste closed EJBTHREE-658.
------------------------------------

    Resolution: Done

> @Resources at class level does not create correct local jndi binding
> --------------------------------------------------------------------
>
>                 Key: EJBTHREE-658
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-658
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>             Fix For: EJB 3.0 RC9 - 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

        


From jira-events at jboss.com  Mon Sep 11 16:27:32 2006
From: jira-events at jboss.com (Marshall Culpepper (JIRA))
Date: Mon, 11 Sep 2006 16:27:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5545432.1158006452562.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343160 ] 
            
Marshall Culpepper commented on JBIDE-354:
------------------------------------------

Hey James..

These icons seem a little 2-tone... not a whole lot of color. I'm guessing you're working with the limitations of the GIF colorspace and replicating the eclipse effect from your new splash.. Do you think instead of pulling from the new splash screen we should start with something fresh for the smaller icons?

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 17:09:30 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 11 Sep 2006 17:09:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-307) Run testsuite in
	Fedore Core 3
In-Reply-To: <9618913.1157811463886.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23375939.1158008970969.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-307?page=all ]

Bela Ban resolved JGRP-307.
---------------------------

    Resolution: Done

runs for me

> Run testsuite in Fedore Core 3
> ------------------------------
>
>                 Key: JGRP-307
>                 URL: http://jira.jboss.com/jira/browse/JGRP-307
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Optional
>             Fix For: 2.4
>
>
> A user reported some failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 17:19:30 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 17:19:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1032) Document
 NavigationPortlet new features
Message-ID: <1491958.1158009570281.JavaMail.jira@cloud.prod.atl2.jboss.com>

Document NavigationPortlet new features
---------------------------------------

                 Key: JBPORTAL-1032
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1032
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


1. excplitict tab ordering
2. localization 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

        


From jira-events at jboss.com  Mon Sep 11 17:27:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 17:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1025) Integrate new
 theme with portal codebase
In-Reply-To: <22595979.1157647004438.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15833922.1158010049462.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1025?page=all ]

Roy Russo resolved JBPORTAL-1025.
---------------------------------

    Resolution: Done

> Integrate new theme with portal codebase
> ----------------------------------------
>
>                 Key: JBPORTAL-1025
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1025
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 17:27:29 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 11 Sep 2006 17:27:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-989) Create new
	Default Theme
In-Reply-To: <30876246.1156181504563.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21098707.1158010049570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-989?page=all ]

Roy Russo resolved JBPORTAL-989.
--------------------------------

    Resolution: Done

> Create new Default Theme
> ------------------------
>
>                 Key: JBPORTAL-989
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-989
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> Use mockup v3 to generate CSS theme.

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 18:27:30 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Mon, 11 Sep 2006 18:27:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3658863.1158013650477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343165 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

___________________________________________________________________________

I've reworked the graphics to be more colorful. I still stayed wlth the "eclipse" because that seems themost appropriate. 


http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm


16 x 16
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside.gif

32 x 32
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside.gif



> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Mon Sep 11 18:59:29 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 18:59:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
Message-ID: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>

Closing connection inside MessageListener's onMessage() causes deadlock
-----------------------------------------------------------------------

                 Key: JBMESSAGING-542
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.0.1.CR5, 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep 11 19:41:29 2006
From: jira-events at jboss.com (Edward Lu (JIRA))
Date: Mon, 11 Sep 2006 19:41:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3643) null message blob is
 created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
Message-ID: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>

null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
-----------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3643
                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Windows XP, Oracle 9.2.0.5
            Reporter: Edward Lu
         Assigned To: Adrian Brock
            Priority: Critical


A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):

I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.

Your help is highly appreciated.

****************************************************************************************
SQL> select count(*) from jms_messages where messageblob is null;

  COUNT(*)
----------
         3

*******************************************************************************************
2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
(java.lang.NullPointerException)^M
        at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
        at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
        at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
        at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M

......
......

Caused by: java.lang.NullPointerException^M
        at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
        at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
        at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
        at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
        at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
        at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M

*******************************************************************************************************************



-- 
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

        


From jira-events at jboss.com  Mon Sep 11 20:37:31 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 20:37:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7779673.1158021451334.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=comments#action_12343169 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-542:
---------------------------------------------

Paliative fix:

      if (Thread.currentThread().equals(sessionExecutor.getThread()))
      {
         // the current thread already closing this MessageCallbackHandler, so no need to register
         // another Closer (see http://jira.jboss.org/jira/browse/JBMESSAGING-542)
         return;
      }

in MessageCallbackHandler.waitForOnMessageToComplete()

However, if we allow the listener to close the connection within onMessage(), then postDeliver() won't be able to pass by session's ClosedInterceptor, which now is "closed", so we'll get an ERROR "Failed to deliver message" in the logs. It's harmless, but ugly. 

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 20:39:29 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 20:39:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14853800.1158021569970.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov updated JBMESSAGING-542:
----------------------------------------

    Comment: was deleted

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 11 20:39:30 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 11 Sep 2006 20:39:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25432712.1158021570083.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=comments#action_12343170 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-542:
---------------------------------------------

Palliative fix:

      if (Thread.currentThread().equals(sessionExecutor.getThread()))
      {
         return;
      }

in MessageCallbackHandler.waitForOnMessageToComplete()

However, if we allow the listener to close the connection within onMessage(), then postDeliver() won't be able to pass by session's ClosedInterceptor, which now is "closed", so we'll get an ERROR "Failed to deliver message" in the logs. It's harmless, but ugly.

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 03:09:32 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Tue, 12 Sep 2006 03:09:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-211) update user guide to
 include new features
In-Reply-To: <24593365.1157241343825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21628852.1158044972483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-211?page=all ]

Alejandro Guizar resolved BPEL-211.
-----------------------------------

    Resolution: Done

Moved examples each to a separate chapter.

> update user guide to include new features
> -----------------------------------------
>
>                 Key: BPEL-211
>                 URL: http://jira.jboss.com/jira/browse/BPEL-211
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>
> -Describe the simplified deployment process
> -Document time-driven activities

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 04:15:31 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Tue, 12 Sep 2006 04:15:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-193) template for new
	projects
Message-ID: <15414913.1158048931430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-193?page=all ]

Alejandro Guizar updated BPEL-193:
----------------------------------

    Fix Version/s:     (was: jBPM BPEL 1.1 beta 2)
                   jBPM BPEL 1.1 beta 3

> template for new projects
> -------------------------
>
>                 Key: BPEL-193
>                 URL: http://jira.jboss.com/jira/browse/BPEL-193
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 3
>
>
> Burr Sutter wrote:
> "I was only hoping for an easy way to build, modify and redeploy HelloWorld or ATM with the least amount of effort.  Something like
> 1. Edit BPEL file
> 2. Deploy
> 3. In the browser view the WSDL
> Having Ant tasks that make it this easy and a template project and build script for getting started would be great for the first release of our BPEL engine."

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:25:40 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 12 Sep 2006 05:25:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
Message-ID: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>

Transaction rollback does not restore contents of collection of cached collections
----------------------------------------------------------------------------------

                 Key: JBCACHE-763
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Nitzan Niv
         Assigned To: Manik Surtani


In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.

1. create 2 "data elements" in the cache which are Map instances.
2. create a "data elements container" in the cache which is a Map instance.
3. initalize the container with one data element.
4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.

After the rollback the element in the container is neither the new data element nor the old data element.

It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:32:43 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 12 Sep 2006 05:32:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCLUSTER-149) Singleton
 failover based on rules
Message-ID: <32376301.1158053564005.JavaMail.jira@cloud.prod.atl2.jboss.com>

Singleton failover based on rules
---------------------------------

                 Key: JBCLUSTER-149
                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-149
             Project: JBoss Clustering
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Galder Zamarreno
         Assigned To: Brian Stansberry


I think that clustering (in this case clustered Singletons) are missing this kind of features. For instance, It would be nice if I had an API where I could:
- Ask the status of each node on the partition (CPU usage, mem usage,...). (This can be done today ...)
- With the data previously collected, my Singleton could decide: Now I wan't to migrate to nobe B because it is with no CPU usage, or because...

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:34:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 12 Sep 2006 05:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2922421.1158053683917.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Nitzan Niv updated JBCACHE-763:
-------------------------------

    Attachment: PojoCollectionRollbackTest.java

test case attached

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Manik Surtani
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:34:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 05:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-764) Update docs,
 examples and tutorial to reflect 2.0.0 API
Message-ID: <29600380.1158053683994.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update docs, examples and tutorial to reflect 2.0.0 API
-------------------------------------------------------

                 Key: JBCACHE-764
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-764
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.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

        


From jira-events at jboss.com  Tue Sep 12 05:36:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 05:36:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCLUSTER-149) Singleton
 failover based on rules
In-Reply-To: <32376301.1158053564005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6709731.1158053803872.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-149?page=all ]

Dimitris Andreadis closed JBCLUSTER-149.
----------------------------------------

    Resolution: Duplicate Issue

See JBAS-3636

> Singleton failover based on rules
> ---------------------------------
>
>                 Key: JBCLUSTER-149
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-149
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>
> I think that clustering (in this case clustered Singletons) are missing this kind of features. For instance, It would be nice if I had an API where I could:
> - Ask the status of each node on the partition (CPU usage, mem usage,...). (This can be done today ...)
> - With the data previously collected, my Singleton could decide: Now I wan't to migrate to nobe B because it is with no CPU usage, or because...

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 05:40:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 12 Sep 2006 05:40:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3643) null message blob is
 created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
In-Reply-To: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24074493.1158054043848.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3643?page=all ]

Adrian Brock closed JBAS-3643.
------------------------------

      Assignee:     (was: Adrian Brock)
    Resolution: Duplicate Issue

> null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Windows XP, Oracle 9.2.0.5
>            Reporter: Edward Lu
>            Priority: Critical
>
> A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):
> I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.
> Your help is highly appreciated.
> ****************************************************************************************
> SQL> select count(*) from jms_messages where messageblob is null;
>   COUNT(*)
> ----------
>          3
> *******************************************************************************************
> 2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
> org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
> (java.lang.NullPointerException)^M
>         at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
>         at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
>         at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
>         at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M
> ......
> ......
> Caused by: java.lang.NullPointerException^M
>         at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
>         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
>         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
>         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
>         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M
> *******************************************************************************************************************

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 06:02:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 06:02:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31731840.1158055363927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Manik Surtani reassigned JBCACHE-763:
-------------------------------------

    Assignee: Ben Wang  (was: Manik Surtani)

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 06:05:34 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 12 Sep 2006 06:05:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-149) Singleton
 failover based on rules
In-Reply-To: <32376301.1158053564005.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18155867.1158055534015.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-149?page=comments#action_12343176 ] 
            
Galder Zamarreno commented on JBCLUSTER-149:
--------------------------------------------

Oops, I missed that one :-)

Thanks

Galder Zamarre?o
Support Engineer
JBoss, a division of Red Hat




> Singleton failover based on rules
> ---------------------------------
>
>                 Key: JBCLUSTER-149
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-149
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Galder Zamarreno
>         Assigned To: Brian Stansberry
>
> I think that clustering (in this case clustered Singletons) are missing this kind of features. For instance, It would be nice if I had an API where I could:
> - Ask the status of each node on the partition (CPU usage, mem usage,...). (This can be done today ...)
> - With the data previously collected, my Singleton could decide: Now I wan't to migrate to nobe B because it is with no CPU usage, or because...

-- 
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

       



From jira-events at jboss.com  Tue Sep 12 07:11:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Tue, 12 Sep 2006 07:11:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-312) Make testsuite
 configurable to run with different stack configurations
Message-ID: <23960957.1158059494513.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make testsuite configurable to run with different stack configurations
----------------------------------------------------------------------

                 Key: JGRP-312
                 URL: http://jira.jboss.com/jira/browse/JGRP-312
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


All test programs should use a system property (with a default if the system property is not defined). The testsuite can then be run with the system property, so all tests use TCP, for example.
We could also use multiple targets, one for each major stack configuration. An 'all-unittests' target would run all of them.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 07:25:35 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 07:25:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3602) 3 failing tests
 org.jboss.test.jacc.test (jrockit)
In-Reply-To: <18072439.1157132983856.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19277784.1158060335880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3602?page=all ]

Dimitris Andreadis closed JBAS-3602.
------------------------------------

         Assignee: Dimitris Andreadis  (was: Anil Saldhana)
    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Fixed

> 3 failing tests org.jboss.test.jacc.test (jrockit)
> --------------------------------------------------
>
>                 Key: JBAS-3602
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3602
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> org.jboss.test.jacc.test
> EJBSpecUnitTestCase(JACC)
> EJBSpecUnitTestCase(JACC+SecurityMgr) 
> testStressNoJaasCache Failure Thread error count == 0
> junit.framework.AssertionFailedError: Thread error count == 0
> 	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStress(EJBSpecUnitTestCase.java:822)
> 	at org.jboss.test.security.test.EJBSpecUnitTestCase.testStressNoJaasCache(EJBSpecUnitTestCase.java:842)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> testGetCallerPrincipal Failure Was able to call StatelessSession.echo
> junit.framework.AssertionFailedError: Was able to call StatelessSession.echo
> 	at org.jboss.test.security.test.EJBSpecUnitTestCase.testGetCallerPrincipal(EJBSpecUnitTestCase.java:194)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 07:37:36 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 07:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3606) failed
 org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
In-Reply-To: <4834417.1157135743871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33350811.1158061056083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3606?page=all ]

Dimitris Andreadis closed JBAS-3606.
------------------------------------

       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Anil Saldhana)
    Fix Version/s: JBossAS-5.0.0.Beta

Fixed

> failed org.jboss.test.naming.test.SecurityUnitTestCase (jrockit)
> ----------------------------------------------------------------
>
>                 Key: JBAS-3606
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3606
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testSecureHttpInvokerFailure Failure
> Should not have been able to lookup(jmx)
> junit.framework.AssertionFailedError: Should not have been able to lookup(jmx)
> 	at org.jboss.test.naming.test.SecurityUnitTestCase.testSecureHttpInvokerFailure(SecurityUnitTestCase.java:77)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Tue Sep 12 07:49:39 2006
From: jira-events at jboss.com (Lubos Lipinsky (JIRA))
Date: Tue, 12 Sep 2006 07:49:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (HIBERNATE-14) Support for
 loading annotations in HAR
Message-ID: <31635403.1158061779079.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/HIBERNATE-14?page=comments#action_12343179 ] 
            
Lubos Lipinsky commented on HIBERNATE-14:
-----------------------------------------

I think this feature is very easy to implement and would help many developers to simplify configuration files maintenance. Why it was removed from all versions?

> Support for loading annotations in HAR
> --------------------------------------
>
>                 Key: HIBERNATE-14
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-14
>             Project: Hibernate
>          Issue Type: Feature Request
>            Reporter: youngm
>         Assigned To: Gavin King
>
> It would be nice to have annotations support for HAR deployments.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:06:33 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:06:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3607) failing
 org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
In-Reply-To: <24350644.1157135863866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24984789.1158062793548.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3607?page=all ]

Dimitris Andreadis closed JBAS-3607.
------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done
         Assignee: Dimitris Andreadis  (was: Scott M Stark)

Fixed

> failing org.jboss.test.session.test.EjbRemoveUnitTestCase (jrockit)
> -------------------------------------------------------------------
>
>                 Key: JBAS-3607
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3607
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2, Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testEjbRemoveNotCalledForEveryCall Failure
> createCounter expected:<1> but was:<0>
> junit.framework.AssertionFailedError: createCounter expected:<1> but was:<0>
> 	at org.jboss.test.session.test.EjbRemoveUnitTestCase.testEjbRemoveNotCalledForEveryCall(EjbRemoveUnitTestCase.java:96)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:10:37 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Tue, 12 Sep 2006 08:10:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-486) Add core and
 compiler support to "collect" conditional element
In-Reply-To: <30283539.1158000824009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26813212.1158063037513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-486?page=all ]

Edson Tirelli resolved JBRULES-486.
-----------------------------------

    Resolution: Done

Support implemented and added to trunk in revision #6167:

----------------
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParser.java
Sending        drools-compiler/src/main/java/org/drools/lang/RuleParserLexer.java
Adding         drools-compiler/src/main/java/org/drools/lang/descr/CollectDescr.java
Sending        drools-compiler/src/main/java/org/drools/lang/descr/DescrFactory.java
Sending        drools-compiler/src/main/java/org/drools/semantics/java/RuleBuilder.java
Sending        drools-compiler/src/main/resources/org/drools/lang/drl.g
Sending        drools-compiler/src/test/java/org/drools/integrationtests/IntegrationCases.java
Sending        drools-compiler/src/test/java/org/drools/integrationtests/LeapsTest.java
Sending        drools-compiler/src/test/java/org/drools/lang/RuleParserTest.java
Adding         drools-compiler/src/test/resources/org/drools/integrationtests/test_Collect.drl
Adding         drools-compiler/src/test/resources/org/drools/lang/collect.drl
Sending        drools-core/src/main/java/org/drools/reteoo/AccumulateNode.java
Adding         drools-core/src/main/java/org/drools/reteoo/CollectNode.java
Sending        drools-core/src/main/java/org/drools/reteoo/ReteooBuilder.java
Adding         drools-core/src/main/java/org/drools/rule/Collect.java
Sending        drools-core/src/main/java/org/drools/rule/Rule.java
Adding         drools-core/src/test/java/org/drools/reteoo/CollectNodeTest.java
Transmitting file data .................
Committed revision 6167.
---------------------

> Add core and compiler support to "collect" conditional element
> --------------------------------------------------------------
>
>                 Key: JBRULES-486
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-486
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Edson Tirelli
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m1
>
>
> Add support for "collect" conditional element into core and compiler components.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:12:30 2006
From: jira-events at jboss.com (Edson Tirelli (JIRA))
Date: Tue, 12 Sep 2006 08:12:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-487) Add eclipse
 plugin support for "collect" conditional element
In-Reply-To: <4117803.1158000824149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2805394.1158063150972.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-487?page=comments#action_12343182 ] 
            
Edson Tirelli commented on JBRULES-487:
---------------------------------------

Kris, support for collect in core and compiler was commited in revision #6167.

There is an integration test you can use:  test_Collect.drl.


> Add eclipse plugin support for "collect" conditional element
> ------------------------------------------------------------
>
>                 Key: JBRULES-487
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-487
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Eclipse IDE
>            Reporter: Edson Tirelli
>         Assigned To: Kris Verlaenen
>             Fix For: 3.1-m1
>
>
> Add support for "collect" conditional element into eclipse plugin.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:18:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:18:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3608) 2 failing tests
 org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
In-Reply-To: <3989808.1157135983973.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24423918.1158063509723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3608?page=all ]

Dimitris Andreadis closed JBAS-3608.
------------------------------------

         Assignee: Dimitris Andreadis  (was: Thomas Diesler)
    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Fixed

> 2 failing tests org.jboss.test.webservice.handlerflow.HandlerFlowTestCase
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3608
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testHandlerFlowServerReturn Failure
> testHandlerFlowAllPass Failure
> Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
> junit.framework.AssertionFailedError: Wrong number of entries: [ClientHandler1 init [handler=31286989,tracker=31131875], ClientHandler2 init [handler=31301135,tracker=31131875], ClientHandler1 handleRequest [handler=31286989,tracker=31131875], ClientHandler2 handleRequest [handler=31301135,tracker=31131875], ServerHandler1 init [handler=31334922,tracker=31131875], ServerHandler2 init [handler=31335085,tracker=31131875], ServerHandler1 handleRequest [handler=31334922,tracker=31131875], ServerHandler2 handleRequest [handler=31335085,tracker=31131875], ServerHandler2 handleResponse [handler=31335085,tracker=31131875], ServerHandler1 handleResponse [handler=31334922,tracker=31131875], ClientHandler2 handleResponse [handler=31301135,tracker=31131875], ClientHandler1 handleResponse [handler=31286989,tracker=31131875], ejb: Return in ServerHandler2] expected:<9> but was:<13>
> 	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.assertHandlerProtocol(HandlerFlowTestCase.java:140)
> 	at org.jboss.test.webservice.handlerflow.HandlerFlowTestCase.testHandlerFlowServerReturn(HandlerFlowTestCase.java:134)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:24:29 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:24:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3609) failing
 org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
In-Reply-To: <23815383.1157135984122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19206095.1158063869987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3609?page=all ]

Dimitris Andreadis closed JBAS-3609.
------------------------------------

       Resolution: Done
    Fix Version/s: JBossAS-5.0.0.Beta
         Assignee: Dimitris Andreadis  (was: Thomas Diesler)

Fixed

> failing org.jboss.test.webservice.jbws70.JBWS70TestCase (jrockit)
> -----------------------------------------------------------------
>
>                 Key: JBAS-3609
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3609
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> testGetVersion Failure
> expected:<Version-1.0> but was:<null>
> junit.framework.ComparisonFailure: expected:<Version-1.0> but was:<null>
> 	at org.jboss.test.webservice.jbws70.JBWS70TestCase.testGetVersion(JBWS70TestCase.java:74)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:44:31 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 12 Sep 2006 08:44:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3610) failing
 org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl)
 (jrockit)
In-Reply-To: <768700.1157136823860.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1344727.1158065071473.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3610?page=all ]

Dimitris Andreadis closed JBAS-3610.
------------------------------------

         Assignee: Dimitris Andreadis  (was: Thomas Diesler)
    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Done

Fixed

> failing org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase(webservice-ssl) (jrockit)
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3610
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3610
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>
> testWithTransportOptions Error
> Call invocation failed: Could not transmit message; nested exception is: javax.xml.soap.SOAPException: Could not transmit message
> java.rmi.RemoteException: Call invocation failed: Could not transmit message; nested exception is: 
> 	javax.xml.soap.SOAPException: Could not transmit message
> 	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:718)
> 	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
> 	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
> 	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
> 	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: javax.xml.soap.SOAPException: Could not transmit message
> 	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:204)
> 	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
> 	... 23 more
> Caused by: org.jboss.remoting.CannotConnectException: Can not connect http client invoker.
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:201)
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
> 	at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:687)
> 	at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:404)
> 	at org.jboss.ws.jaxrpc.CallProxy.invoke(CallProxy.java:148)
> 	at $Proxy3.sayHello(Ljava.lang.String;)Ljava.lang.String;(Unknown Source)
> 	at org.jboss.test.webservice.secure.noenv.TransportOptionsTestCase.testWithTransportOptions(TransportOptionsTestCase.java:83)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: bad_certificate
> 	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(BLjava.lang.Throwable;Ljava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(BLjava.lang.String;)Ljavax.net.ssl.SSLException;(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush()V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_bc;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_az.j()V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(Lcom.sun.net.ssl.internal.ssl.SunJSSE_ba;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_az.a(BI)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SunJSSE_ax.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Lcom.sun.net.ssl.internal.ssl.InputRecord;Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j()V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Z)V(DashoA12275:???)
> 	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake()V(DashoA12275:???)
> 	at sun.net.www.protocol.https.HttpsClient.afterConnect()V(DashoA12275:???)
> 	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect()V(DashoA12275:???)
> 	at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:569)
> 	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream()Ljava.io.OutputStream;(DashoA12275:???)
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:163)
> 	at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.ws.soap.SOAPConnectionImpl.call(SOAPConnectionImpl.java:189)
>  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:44:31 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 12 Sep 2006 08:44:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-749) extra configuration
 parameters for jbpm thread servlet
Message-ID: <9684337.1158065071611.JavaMail.jira@cloud.prod.atl2.jboss.com>

extra configuration parameters for jbpm thread servlet
------------------------------------------------------

                 Key: JBPM-749
                 URL: http://jira.jboss.com/jira/browse/JBPM-749
             Project: JBoss jBPM
          Issue Type: Feature Request
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3


Following servlet init configuration parameters are added to the JbpmThreadServlet:

commandExecutorInterval: time in milliseconds between two subsequent checks for messages by the command executor thread.  default is 5000.

schedulerInterval: time in milliseconds between two subsequent checks for timers by the scheduler thread.  default is 5000.

priority: priority of the command executor and scheduler threads. default is 1.

maxResultCount: max number of timers processed per transaction.  default is 1.



-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:54:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 12 Sep 2006 08:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-749) extra configuration
 parameters for jbpm thread servlet
In-Reply-To: <9684337.1158065071611.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20168580.1158065672520.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-749?page=all ]

Tom Baeyens updated JBPM-749:
-----------------------------

    Attachment: jbpm-3.1.3-snapshot.jar

added a jbpm lib, which is a snapshot build inbetween 3.1.2 and the upcoming 3.1.3.  it includes these extra configuration parameters.  please, let us know if you you are able to try this out and give us some feedback.

> extra configuration parameters for jbpm thread servlet
> ------------------------------------------------------
>
>                 Key: JBPM-749
>                 URL: http://jira.jboss.com/jira/browse/JBPM-749
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3
>
>         Attachments: jbpm-3.1.3-snapshot.jar
>
>
> Following servlet init configuration parameters are added to the JbpmThreadServlet:
> commandExecutorInterval: time in milliseconds between two subsequent checks for messages by the command executor thread.  default is 5000.
> schedulerInterval: time in milliseconds between two subsequent checks for timers by the scheduler thread.  default is 5000.
> priority: priority of the command executor and scheduler threads. default is 1.
> maxResultCount: max number of timers processed per transaction.  default is 1.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:54:32 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 12 Sep 2006 08:54:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-749) extra configuration
 parameters for jbpm thread servlet
In-Reply-To: <9684337.1158065071611.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13203890.1158065672689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-749?page=all ]

Tom Baeyens closed JBPM-749.
----------------------------

    Resolution: Done

> extra configuration parameters for jbpm thread servlet
> ------------------------------------------------------
>
>                 Key: JBPM-749
>                 URL: http://jira.jboss.com/jira/browse/JBPM-749
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3
>
>         Attachments: jbpm-3.1.3-snapshot.jar
>
>
> Following servlet init configuration parameters are added to the JbpmThreadServlet:
> commandExecutorInterval: time in milliseconds between two subsequent checks for messages by the command executor thread.  default is 5000.
> schedulerInterval: time in milliseconds between two subsequent checks for timers by the scheduler thread.  default is 5000.
> priority: priority of the command executor and scheduler threads. default is 1.
> maxResultCount: max number of timers processed per transaction.  default is 1.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 08:56:34 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 08:56:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-434) InternalDelegate
 doesn't relocate AOP nodes properly
Message-ID: <27446258.1158065794106.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-434?page=all ]

Ben Wang resolved JBCACHE-434.
------------------------------

    Resolution: Out of Date

Since PojoCache object mapping has been refactored in 2.0, this issue should not relevant anymore.

> InternalDelegate doesn't relocate AOP nodes properly
> ----------------------------------------------------
>
>                 Key: JBCACHE-434
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-434
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.2.4SP1
>            Reporter: twundke
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: relocate.txt
>
>
> When the object graph handler attempts to remove a node that has references to it, it relocates the data to the first referencing FQN in the list. However, InternalDelegate.relocate() fails to correctly update the AOP references. There is some commented-out code that seems to attempt to update the indirect FQN.
> I've attatched my updated code (for our demo), but it's overly complicated due to lack of time, sleep etc. In fact it fully updates the internal state of the cache for the node (including changing the indirect FQN, and changing all references to point to the new indirect FQN), which was the quickest way to get a solution at the time. You can probably cut out half of this by simply updating the indirect FQN correctly, which I presume was the intent in the first place. However, I believe this still only half-solves the problem as the reference counts need to be updated.
> Sorry if this is a bit of a vague bug report Ben, but I can't fully remember my thinking at the time. Hopefully my code at least shows all that has to be done to keep the cache consistent.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 09:00:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Tue, 12 Sep 2006 09:00:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-303) Verify that all
 synchronized statements have short scopes
In-Reply-To: <292182.1157790209387.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15295867.1158066033267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-303?page=all ]

Bela Ban updated JGRP-303:
--------------------------

    Fix Version/s:     (was: 2.4)
                   2.5

> 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.5
>
>
> 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

        


From jira-events at jboss.com  Tue Sep 12 09:02:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Tue, 12 Sep 2006 09:02:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-313) MultiplexerTests
 don't work with TCP configuration
Message-ID: <15805211.1158066153671.JavaMail.jira@cloud.prod.atl2.jboss.com>

MultiplexerTests don't work with TCP configuration
--------------------------------------------------

                 Key: JGRP-313
                 URL: http://jira.jboss.com/jira/browse/JGRP-313
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


UDP works 100%, however, some of the tests fail with a TCP configuration

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:39:36 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Tue, 12 Sep 2006 11:39:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-765) implementation of
 equals() in collections is incorrect
Message-ID: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>

implementation of equals() in collections is incorrect
------------------------------------------------------

                 Key: JBCACHE-765
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Nitzan Niv
         Assigned To: Ben Wang


The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).



-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:41:39 2006
From: jira-events at jboss.com (Arik Kfir (JIRA))
Date: Tue, 12 Sep 2006 11:41:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-661) Security:
 Deploying a bean
 without mandatory org.jboss.ejb3.security.SecurityDomain results in a
 NullPointerException
In-Reply-To: <7251726.1153836311374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18715455.1158075699713.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-661?page=comments#action_12343193 ] 
            
Arik Kfir commented on EJBTHREE-661:
------------------------------------

Did you try setting it in the ejb-jar's jboss.xml descriptor? 

> Security: Deploying a bean without mandatory org.jboss.ejb3.security.SecurityDomain results in a NullPointerException
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-661
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-661
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: EJB 3.0 RC7 - FD
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>             Fix For: EJB 3.0 RC10 - FD
>
>
> When setting up security in a EJB3 bean, it is mandatory adding the 
> org.jboss.ejb3.security.SecurityDomain tag. Failure to do so results 
> on a NullPointerException. 
> AS should log a more meaningful message rather than a 
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:46:34 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 12 Sep 2006 11:46:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-489) Category to have
 seperate "add" method (not getOrCreateCategory)
Message-ID: <14203982.1158075994710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Category to have seperate "add" method (not getOrCreateCategory)
----------------------------------------------------------------

                 Key: JBRULES-489
                 URL: http://jira.jboss.com/jira/browse/JBRULES-489
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:48:37 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Tue, 12 Sep 2006 11:48:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-489) Category to have
 seperate "add" method (not getOrCreateCategory)
In-Reply-To: <14203982.1158075994710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22247034.1158076117159.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-489?page=comments#action_12343194 ] 
            
Michael Neale commented on JBRULES-489:
---------------------------------------

perhaps its better to have category added seperately (plus category will have meta data like description).

> Category to have seperate "add" method (not getOrCreateCategory)
> ----------------------------------------------------------------
>
>                 Key: JBRULES-489
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-489
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 11:48:37 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 11:48:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-4) Evaluate OpenDS
 (Sun's OSS all-java Directory Server)
Message-ID: <3697073.1158076117046.JavaMail.jira@cloud.prod.atl2.jboss.com>

Evaluate OpenDS (Sun's OSS all-java Directory Server)
-----------------------------------------------------

                 Key: SECURITY-4
                 URL: http://jira.jboss.com/jira/browse/SECURITY-4
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Anil Saldhana
         Assigned To: Scott M Stark


https://opends.dev.java.net/public/docs/OpenDS-FAQ.html

- Requires JDK5. 
- Java only.
- Ldif import/export supported.

Good candidate for HEAD testsuite integration.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:41:40 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 12:41:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
Message-ID: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>

Don't return unnecessary values from _replicate, avoiding need for marshalling
------------------------------------------------------------------------------

                 Key: JBCACHE-766
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
             Project: JBoss Cache
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani
            Priority: Minor
             Fix For: 1.4.0.SP2


This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
responses passed over RpcDispatcher as well as for requests, but is a simpler and
less general fix.

Right now if you set a class loader for a tree cache region, it works for request parameters,
but is ignored for returns. If there is an attempt to return a value that needs to be loaded
with the class loader, an exception will be thrown.

The only return value in normal REPL_SYNC operation is the return value from 
the key-value put methods, which is the old value, if any. But that return value isn't
needed for replication. So, this patch just nulls out the return value from the two affected
methods.

(We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
entities are stored directly in the cache, and are serialized/deserialized on replication.
There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
hacky manner.)



-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:43:32 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 12:43:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-756) Marshaller
 breaks with Strings of length greater than 32767
In-Reply-To: <28986578.1156934144423.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25000128.1158079412860.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-756?page=comments#action_12343196 ] 
            
Manik Surtani commented on JBCACHE-756:
---------------------------------------

This may just be a problem with jboss-serialization.jar and nothing to do with JBoss Cache at all.  Clebert's investigating the potential problem with jboss-serialization.

FYI, JBoss Cache 1.4.0.GA and 1.4.0.SP1 both ship with jboss-serialization-1.0.1.GA.  The potential upside is that if it is a bug in jboss-serialization, fixing the issue will just be upgrading the one jar, and it should be backward-compatible with JBoss Cache 1.4.0.XX.



> Marshaller breaks with Strings of length greater than 32767
> -----------------------------------------------------------
>
>                 Key: JBCACHE-756
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-756
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>    Affects Versions: 1.4.0, 1.4.0.SP1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> See unit tests added.  

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:45:35 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 12:45:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14013080.1158079535628.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Owen Taylor updated JBCACHE-766:
--------------------------------

    Attachment: jbosscache-avoid-return-20060912.patch

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:47:36 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 12:47:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24954112.1158079656489.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343197 ] 
            
Owen Taylor commented on JBCACHE-766:
-------------------------------------

> But that return value isn't needed for replication. So, this patch just nulls out the return value 
> from the two affected methods. 

That's sort of unclear, actually. To clarify: it nulls out the return values when returning them from
_replicate. The actual underlying methods are unmodified.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 12:49:34 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 12 Sep 2006 12:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
Message-ID: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>

StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
------------------------------------------------------------------------------------------------------------------------

                 Key: JBSER-89
                 URL: http://jira.jboss.com/jira/browse/JBSER-89
             Project: JBoss Serialization
          Issue Type: Bug
    Affects Versions: 1.0.2 GA, 1.0.1 GA
            Reporter: Manik Surtani
         Assigned To: Clebert Suconic


See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:23:36 2006
From: jira-events at jboss.com (Richard Brooks (JIRA))
Date: Tue, 12 Sep 2006 13:23:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-262) Add another
 addFromResourceBundle method to class FacesMessages
Message-ID: <29443818.1158081816808.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-262?page=comments#action_12343198 ] 
            
Richard Brooks commented on JBSEAM-262:
---------------------------------------

(already posted on forum see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90463)

Looking at the diff it appears that the id parameter has been added to the method signatures but isn't passed through unless you use the method with all the parameters (severity, default, etc)

(diff http://fisheye.jboss.org/viewrep/JBoss/jboss-seam/src/main/org/jboss/seam/core/FacesMessages.java?r1=1.17&r2=1.18)

I haven't actually run the code as I only came across it trying to do the same thing in 1.0.1 GA so I could be mistaken

> Add another addFromResourceBundle method to class FacesMessages
> ---------------------------------------------------------------
>
>                 Key: JBSEAM-262
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-262
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>            Reporter: Bruce Raggett
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Is it possible to add another addFromResourceBundle method to class FacesMessages which would accept a JSF component id parameter? This enhancement would make it easy for a session bean to display a localized message from the resource bundle against a specific JSF input field.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:27:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 13:27:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-315) Break locks for
	state transfer
Message-ID: <12363765.1158082054842.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]

Brian Stansberry updated JBCACHE-315:
-------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76038

> Break locks for state transfer
> ------------------------------
>
>                 Key: JBCACHE-315
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-315
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>            Priority: Critical
>             Fix For: 2.1.0
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:27:35 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Tue, 12 Sep 2006 13:27:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3644) ejbqltosql92compiler
 creates LEFT OUTER JOIN when INNER JOIN would be faster
Message-ID: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>

ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
----------------------------------------------------------------------------

                 Key: JBAS-3644
                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.0.3 SP1
         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
            Reporter: anajavi
         Assigned To: Alexey Loubyansky


Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 

Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).

I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.

I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).

I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.

Example:
Original EJBQL:

SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2

Generated SQL:

SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o 
LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'


10x faster SQL:

SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
FROM rooli t0_o 
INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'

Thank you.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:33:34 2006
From: jira-events at jboss.com (Edward Lu (JIRA))
Date: Tue, 12 Sep 2006 13:33:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3643) null message blob
 is created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
In-Reply-To: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24518950.1158082414066.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3643?page=all ]

Edward Lu reopened JBAS-3643:
-----------------------------

             
Please indicate the duplicate bug number.  As of 4.0.4 GA, the issue is not fixed.  

In OracleThinPersistenceManager.add, after the LOCK_EMPTY_BLOB (select messageblob for update), it closes statement and result set, and then does a UPDATE_MESSAGE (update messageblob) instead of writing message content into blob locator.  The code works for message < 4k but not message > 4k.



> null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Windows XP, Oracle 9.2.0.5
>            Reporter: Edward Lu
>            Priority: Critical
>
> A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):
> I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.
> Your help is highly appreciated.
> ****************************************************************************************
> SQL> select count(*) from jms_messages where messageblob is null;
>   COUNT(*)
> ----------
>          3
> *******************************************************************************************
> 2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
> org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
> (java.lang.NullPointerException)^M
>         at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
>         at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
>         at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
>         at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M
> ......
> ......
> Caused by: java.lang.NullPointerException^M
>         at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
>         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
>         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
>         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
>         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M
> *******************************************************************************************************************

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:54:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 13:54:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10553249.1158083684027.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Brian Stansberry updated JBCACHE-766:
-------------------------------------

    Fix Version/s:     (was: 1.4.0.SP2)

Interesting.  I think JBCACHE-752 is the right solution for the marshalling issue (doing it well gives the opportunity to add efficiencies in addition to fixing classloading).  But, you're right -- if we're returning a value from a replicated put, that's not necessary and beyond potential classloading problems it's wasted effort.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 13:54:44 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 13:54:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23485887.1158083684215.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343203 ] 
            
Brian Stansberry commented on JBCACHE-766:
------------------------------------------

I removed the Fix Version, as that decision i's neither of our's; it's Manik Surtani's.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:00:44 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 14:00:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3995603.1158084044085.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=comments#action_12343204 ] 
            
Owen Taylor commented on JBCACHE-766:
-------------------------------------

Sorry about the fix version ... I thought that was the affected version field. I (happily)
don't have the sort of familiarity with the JIRA UI that I have with bugzilla.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:12:43 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Tue, 12 Sep 2006 14:12:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1029) Ability for an
 administrator to add/remove users
In-Reply-To: <31634122.1157978131703.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33439732.1158084763863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1029?page=all ]

Roy Russo resolved JBPORTAL-1029.
---------------------------------

    Resolution: Done

> Ability for an administrator to add/remove users
> ------------------------------------------------
>
>                 Key: JBPORTAL-1029
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1029
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.4.1 Final, 2.6.Alpha1
>            Reporter: Morten Hauch
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: userportlet.zip
>
>
> In the UserPortlet it should be possible to portal administrators to create new users and delete users.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:24:32 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 14:24:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-767) Fail more silently
 when setting node versions
Message-ID: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fail more silently when setting node versions
---------------------------------------------

                 Key: JBCACHE-767
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
             Project: JBoss Cache
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani
            Priority: Minor
         Attachments: jbosscache-fail-more-silently-20060912.patch

Hibernate's OptimisticTreeCache.writeUpdate does:

                        Option option = new Option();
                        option.setFailSilently( true );
                        option.setDataVersion( NonLockingDataVersion.INSTANCE );
                        cache.remove( new Fqn( regionFqn, key ), "ITEM", option );

Which you would expect would remove the item if it exists, while setting the data version,
and silently do nothing otherwise. But it ends up, logging at level INFO:

12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
java.lang.NullPointerException
        at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
        at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
        at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
        at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
        at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
        at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)

There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
problem.

What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
NullPointerException.




-- 
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

        


From jira-events at jboss.com  Tue Sep 12 14:24:33 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 12 Sep 2006 14:24:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-767) Fail more silently
 when setting node versions
In-Reply-To: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4388295.1158085473071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]

Owen Taylor updated JBCACHE-767:
--------------------------------

    Attachment: jbosscache-fail-more-silently-20060912.patch

> Fail more silently when setting node versions
> ---------------------------------------------
>
>                 Key: JBCACHE-767
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>         Attachments: jbosscache-fail-more-silently-20060912.patch
>
>
> Hibernate's OptimisticTreeCache.writeUpdate does:
>                         Option option = new Option();
>                         option.setFailSilently( true );
>                         option.setDataVersion( NonLockingDataVersion.INSTANCE );
>                         cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
> Which you would expect would remove the item if it exists, while setting the data version,
> and silently do nothing otherwise. But it ends up, logging at level INFO:
> 12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
> java.lang.NullPointerException
>         at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
>         at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
>         at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
>         at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
> There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
> too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
> problem.
> What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
> setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:08:31 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Tue, 12 Sep 2006 15:08:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26919603.1158088111632.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343208 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

Iv'e also made a second version of the icon using the JBOSS corporate red.


http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm


16 x 16
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside_2.gif

32 x 32
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside_v2.gif

They can be seen in action here:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_jbosside_page_v2.gif

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:26:35 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 15:26:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-5) Integrate OpenDS in
 HEAD testsuite
Message-ID: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate OpenDS in HEAD testsuite
----------------------------------

                 Key: SECURITY-5
                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule

Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.

My prelim testing details:
====================================================================
C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
[12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
 Directory Server 0.1-build007 starting up."
[12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
database backend containing 1 entries has started."
[12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
msg="Access control has been disabled."
[12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
rectory Server has started successfully."
[12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
rectory Server has sent an alert notification generated by class org.opends.serv
er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
ert ID 458887):  The Directory Server has started successfully.."
================================================================================


=============================================================================
C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
-D "cn=Directory Manager" -w password -a -f a.ldif

Processing ADD request for dc=jboss,dc=org.

ADD operation successful for DN dc=jboss,dc=org.

Processing ADD request for ou=People,dc=jboss,dc=org.

ADD operation successful for DN ou=People,dc=jboss,dc=org.

Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.

ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.

Processing ADD request for ou=Roles,dc=jboss,dc=org.

ADD operation successful for DN ou=Roles,dc=jboss,dc=org.

Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.

ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.

Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.

ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
===============================================================================

==============================================================================
C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
 -b "dc=jboss,dc=org" -s sub "objectclass=*"

dn: dc=jboss,dc=org

objectClass: top

objectClass: dcObject

objectClass: organization

o: JBoss

dc: jboss

dn: ou=People,dc=jboss,dc=org

objectClass: top

objectClass: organizationalUnit

ou: People

dn: uid=jduke,ou=People,dc=jboss,dc=org

objectClass: top
objectClass: person
objectClass: uidObject
userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
cn: Java Duke
sn: Duke
uid: jduke
=====================================================================================

The application policy:
<application-policy name = "jmx-console">
        <authentication>
            <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
                          flag="required">
                <module-option name="java.naming.factory.initial"> 
                    com.sun.jndi.ldap.LdapCtxFactory
                    </module-option>
                <module-option name="java.naming.provider.url">
                    ldap://localhost:389/
                </module-option>
                <module-option name="java.naming.security.authentication">
                    simple
                </module-option>
                <module-option name="principalDNPrefix">uid=</module-option>                    
                <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
                <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
                <module-option name="uidAttributeID">member</module-option>
                <module-option name="matchOnUserDN">true</module-option>
                <module-option name="roleAttributeID">cn</module-option>
                <module-option name="roleAttributeIsDN">false</module-option>
                <module-option name="searchTimeLimit">5000</module-option>
                <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
            </login-module>
        </authentication>
    </application-policy>


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:26:36 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 15:26:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (SECURITY-4) Evaluate OpenDS
 (Sun's OSS all-java Directory Server)
In-Reply-To: <3697073.1158076117046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14329396.1158089196086.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-4?page=all ]

Anil Saldhana reassigned SECURITY-4:
------------------------------------

    Assignee: Anil Saldhana  (was: Scott M Stark)

> Evaluate OpenDS (Sun's OSS all-java Directory Server)
> -----------------------------------------------------
>
>                 Key: SECURITY-4
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-4
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> https://opends.dev.java.net/public/docs/OpenDS-FAQ.html
> - Requires JDK5. 
> - Java only.
> - Ldif import/export supported.
> Good candidate for HEAD testsuite integration.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:26:36 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 15:26:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-4) Evaluate OpenDS
 (Sun's OSS all-java Directory Server)
In-Reply-To: <3697073.1158076117046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32882535.1158089196236.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-4?page=all ]

Anil Saldhana closed SECURITY-4.
--------------------------------

    Resolution: Done

Preliminary testing has been successful as outlined in SECURITY-5

Will attempt integration in HEAD testsuite.

> Evaluate OpenDS (Sun's OSS all-java Directory Server)
> -----------------------------------------------------
>
>                 Key: SECURITY-4
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-4
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> https://opends.dev.java.net/public/docs/OpenDS-FAQ.html
> - Requires JDK5. 
> - Java only.
> - Ldif import/export supported.
> Good candidate for HEAD testsuite integration.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:48:34 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 15:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3645) LdapExtLoginModule
 still has connection leak
Message-ID: <20371850.1158090514725.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule still has connection leak
--------------------------------------------

                 Key: JBAS-3645
                 URL: http://jira.jboss.com/jira/browse/JBAS-3645
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:56:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 15:56:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3646) LdapExtLoginModule
 still has connection leak
Message-ID: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule still has connection leak
--------------------------------------------

                 Key: JBAS-3646
                 URL: http://jira.jboss.com/jira/browse/JBAS-3646
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA


The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 15:56:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 15:56:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (SECURITY-6) LdapExtLoginModule
 still has connection leak
In-Reply-To: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17624522.1158090999813.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-6?page=all ]

Scott M Stark moved JBAS-3646 to SECURITY-6:
--------------------------------------------

    Affects Version/s:     (was: JBossAS-4.0.4.GA)
              Project: JBoss Security  (was: JBoss Application Server)
                  Key: SECURITY-6  (was: JBAS-3646)
          Component/s: JBossSX
                           (was: Security)
        Fix Version/s:     (was: JBossAS-5.0.0.Beta)
                           (was: JBossAS-4.0.5.GA)

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: SECURITY-6
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-6
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 16:31:36 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Tue, 12 Sep 2006 16:31:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-749) Make
 BdbjeCacheLoader use the
 standard format for persistent state transfer
In-Reply-To: <17190799.1156632131571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23942570.1158093096927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-749?page=all ]

Vladimir Blagojevic resolved JBCACHE-749.
-----------------------------------------

    Resolution: Done

Resolved by moving storeState/loadState methods up to AbstractCacheLoader

> Make BdbjeCacheLoader use the standard format for persistent state transfer
> ---------------------------------------------------------------------------
>
>                 Key: JBCACHE-749
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-749
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>            Reporter: Brian Stansberry
>
> The state should be a sequence of NodeData objects; see FileCacheLoader or JDBCCacheLoader.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 16:49:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 12 Sep 2006 16:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (SECURITY-6) LdapExtLoginModule
 still has connection leak
In-Reply-To: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24472954.1158094174956.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-6?page=all ]

Anil Saldhana updated SECURITY-6:
---------------------------------

    Affects Version/s: 2.0
                       1.x
        Fix Version/s: 1.x
                       2.0

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: SECURITY-6
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-6
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 1.x, 2.0
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.x, 2.0
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:34:35 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 17:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3645) LdapExtLoginModule
 still has connection leak
In-Reply-To: <20371850.1158090514725.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1700732.1158096875411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3645?page=all ]

Scott M Stark closed JBAS-3645.
-------------------------------

    Resolution: Done

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3645
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3645
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:34:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 12 Sep 2006 17:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-541) Crash Test
 failure on Durable Subscriber
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9996235.1158096875588.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic reassigned JBMESSAGING-541:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Tom  Elrod)

> Crash Test failure on Durable Subscriber
> ----------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> DurableSubscriberCrashTest1 and 2 are failing.
> The routine that verifies if a connection is broken is only called upon communication exceptions. 
> If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:36:32 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 17:36:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3647) Backport
 SingleRetryInterceptor to 3.2
Message-ID: <4654533.1158096992808.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport SingleRetryInterceptor to 3.2
--------------------------------------

                 Key: JBAS-3647
                 URL: http://jira.jboss.com/jira/browse/JBAS-3647
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Clustering, EJB2
    Affects Versions: JBossAS-3.2.8.SP1
            Reporter: Scott M Stark
         Assigned To: Brian Stansberry


A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1:

2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException:
org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132)
at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143)
at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918)

We should backport this.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 17:38:37 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 17:38:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3648) Need a clustered ejb
 compatibility test
Message-ID: <17070980.1158097117897.JavaMail.jira@cloud.prod.atl2.jboss.com>

Need a clustered ejb compatibility test
---------------------------------------

                 Key: JBAS-3648
                 URL: http://jira.jboss.com/jira/browse/JBAS-3648
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-3.2.8.SP1
            Reporter: Scott M Stark
         Assigned To: Brian Stansberry


We need a test of a 3.2.x client talking to a 4.0.x clustered ejb to validate interop.


-- 
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

        


From jira-events at jboss.com  Tue Sep 12 18:04:31 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Tue, 12 Sep 2006 18:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1033) PortletContainer
 added logging causes class loading issues.
Message-ID: <4364937.1158098671693.JavaMail.jira@cloud.prod.atl2.jboss.com>

PortletContainer added logging causes class loading issues.
-----------------------------------------------------------

                 Key: JBPORTAL-1033
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1033
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4 Final, 2.2.1 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1


In PortletContainer constructor:
this.portletLog = Logger.getLogger(metaData.getClassName());
causes Log4J to be loaded in several different class loaders causing CCEs.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 18:10:31 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 12 Sep 2006 18:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-6) LdapExtLoginModule
 still has connection leak
In-Reply-To: <6883582.1158090999687.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22404453.1158099031127.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-6?page=all ]

Scott M Stark closed SECURITY-6.
--------------------------------

    Resolution: Done

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: SECURITY-6
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-6
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 1.x, 2.0
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.x, 2.0
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:36:44 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32382560.1158107804279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Ben Wang updated JBCACHE-765:
-----------------------------

    Fix Version/s: 2.0.0

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:36:44 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:36:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-765) implementation
 of equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19845506.1158107804439.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=comments#action_12343226 ] 
            
Ben Wang commented on JBCACHE-765:
----------------------------------

I can take a look early next week. Or do you have a patch ready that you can attach?

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:38:43 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12260377.1158107923972.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Ben Wang updated JBCACHE-763:
-----------------------------

    Fix Version/s: 2.0.0

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:40:43 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 12 Sep 2006 20:40:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26333263.1158108043891.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Ben Wang updated JBCACHE-760:
-----------------------------

    Fix Version/s: 2.0.0
                   1.4.0.SP2

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0, 1.4.0.SP2
>
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 20:56:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 12 Sep 2006 20:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21773216.1158109003844.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Description: 
IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:


	      conn1 = cf.createConnection();
	      conn1.setClientID("test1");
	      conn1.start();

	      conn2 = cf.createConnection();
	      conn2.setClientID("test2");
	      conn2.start();

	      conn1.close();


  was:
DurableSubscriberCrashTest1 and 2 are failing.
The routine that verifies if a connection is broken is only called upon communication exceptions. 

If the connection is only closed, there is no PING routine verifying this. (not that I at least could see it).

        Summary: If the first opened connections is closed, Remoting Lease doesn't work any more  (was: Crash Test failure on Durable Subscriber)

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 12 20:56:44 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 12 Sep 2006 20:56:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17410853.1158109004019.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Comment: was deleted

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 12 21:10:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 21:10:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3639) Lookup fails during
	failover
In-Reply-To: <8989834.1157983952060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <264847.1158109843912.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3639?page=all ]

Brian Stansberry updated JBAS-3639:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90404  (was: http://jboss.com/index.html?module=bb&op=viewtopic&p=3949184#3949184)

For whatever reason our forum wouldn't let me reply to the forum thread you opened a while back, so I just started a new one at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90404 and replied there.

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBAS-3639
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3639
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.6 Final, JBossAS-4.0.4RC1
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534)
> This happened on our test cluster.
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.
> I tested with jboss 4.0.4 and the problem still exists

-- 
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

        


From jira-events at jboss.com  Tue Sep 12 22:00:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 12 Sep 2006 22:00:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3649) Startup switches
 should set the new JGroups system properties
Message-ID: <13306029.1158112843780.JavaMail.jira@cloud.prod.atl2.jboss.com>

Startup switches should set the new JGroups system properties
-------------------------------------------------------------

                 Key: JBAS-3649
                 URL: http://jira.jboss.com/jira/browse/JBAS-3649
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


JGroups has created a more formalized system for the names of the system properties it uses (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps).  We need to ensure that when the JBoss AS command-line switches are used, the new system properties get set:

-b jgroups.bind_addr
-u  jgroups.udp.mcast_addr

The old properties will be set as well to ensure legacy config files still work.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 00:00:31 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 00:00:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3650) LdapExtLoginModule
 still has connection leak
Message-ID: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule still has connection leak
--------------------------------------------

                 Key: JBAS-3650
                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 00:17:43 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 00:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3120192.1158121063856.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3650?page=comments#action_12343229 ] 
            
Scott M Stark commented on JBAS-3650:
-------------------------------------

[sstark at sstark Patches]$ svn copy -m "Patch for LdapExtLoginModule still has connection leak" https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_3_SP1 https://svn.jboss.org/repos/jbossas/branches/JBoss_4_0_3_SP1_JBAS-3650

Committed revision 56790.


> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 02:49:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 13 Sep 2006 02:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3649) Startup switches
 should set the new JGroups system properties
In-Reply-To: <13306029.1158112843780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21070985.1158130183806.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3649?page=comments#action_12343230 ] 
            
Dimitris Andreadis commented on JBAS-3649:
------------------------------------------

Nice. You should rename your Wiki Page though:

SystemProps --> JGroupSystemProps

:-)

> Startup switches should set the new JGroups system properties
> -------------------------------------------------------------
>
>                 Key: JBAS-3649
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3649
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.Beta
>
>
> JGroups has created a more formalized system for the names of the system properties it uses (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps).  We need to ensure that when the JBoss AS command-line switches are used, the new system properties get set:
> -b jgroups.bind_addr
> -u  jgroups.udp.mcast_addr
> The old properties will be set as well to ensure legacy config files still work.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 03:29:44 2006
From: jira-events at jboss.com (Richard C. L. Li (JIRA))
Date: Wed, 13 Sep 2006 03:29:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3385) cmp2.x jdbc2 pm
 Failed to Deploy
 2 Identical EARs with Different Datasource Configuration
In-Reply-To: <703339.1152676762037.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22435302.1158132584973.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3385?page=all ]

Richard C. L. Li updated JBAS-3385:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> cmp2.x jdbc2 pm Failed to Deploy 2 Identical EARs with Different Datasource Configuration
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-3385
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3385
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Richard C. L. Li
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: EntityTable.diff
>
>
> Deploying 2 Identical EARs with different datasource configuration will generate the following exception:
> 2006-07-11 12:54:36,458 INFO  [org.jboss.ejb.plugins.cmp.jdbc2.schema.PartitionedTableCache] Registration is not done -> stop
> 2006-07-11 12:54:36,458 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:module=retailsales.jar,uid=12606869,service=EjbModule
> org.jboss.deployment.DeploymentException: Failed to register table cache for memo; - nested throwable: (javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:216)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.Schema.createEntityTable(Schema.java:93)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.bridge.JDBCEntityBridge2.<init>(JDBCEntityBridge2.java:80)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.initStoreManager(JDBCStoreManager2.java:437)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.start(JDBCStoreManager2.java:175)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
> 	at org.jboss.ejb.EntityContainer.startPmAndInterceptors(EntityContainer.java:1063)
> 	at org.jboss.ejb.EjbModule.startService(EjbModule.java:422)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy16.start(Unknown Source)
> 	at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
> 	at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy17.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> 	at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy8.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
> Caused by: javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:761)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:225)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:211)
> 	... 67 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 03:47:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 13 Sep 2006 03:47:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3385) cmp2.x jdbc2 pm
 Failed to Deploy
 2 Identical EARs with Different Datasource Configuration
In-Reply-To: <703339.1152676762037.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32710194.1158133663924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3385?page=all ]

Dimitris Andreadis updated JBAS-3385:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

Please, let the developer define the fix version.

> cmp2.x jdbc2 pm Failed to Deploy 2 Identical EARs with Different Datasource Configuration
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-3385
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3385
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Richard C. L. Li
>         Assigned To: Alexey Loubyansky
>         Attachments: EntityTable.diff
>
>
> Deploying 2 Identical EARs with different datasource configuration will generate the following exception:
> 2006-07-11 12:54:36,458 INFO  [org.jboss.ejb.plugins.cmp.jdbc2.schema.PartitionedTableCache] Registration is not done -> stop
> 2006-07-11 12:54:36,458 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.j2ee:module=retailsales.jar,uid=12606869,service=EjbModule
> org.jboss.deployment.DeploymentException: Failed to register table cache for memo; - nested throwable: (javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:216)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.Schema.createEntityTable(Schema.java:93)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.bridge.JDBCEntityBridge2.<init>(JDBCEntityBridge2.java:80)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.initStoreManager(JDBCStoreManager2.java:437)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.JDBCStoreManager2.start(JDBCStoreManager2.java:175)
> 	at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:172)
> 	at org.jboss.ejb.EntityContainer.startPmAndInterceptors(EntityContainer.java:1063)
> 	at org.jboss.ejb.EjbModule.startService(EjbModule.java:422)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> 	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> 	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> 	at $Proxy0.start(Unknown Source)
> 	at org.jboss.system.ServiceController.start(ServiceController.java:417)
> 	at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy16.start(Unknown Source)
> 	at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:662)
> 	at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy17.start(Unknown Source)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
> 	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:997)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
> 	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
> 	at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy8.deploy(Unknown Source)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> 	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
> 	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
> Caused by: javax.management.InstanceAlreadyExistsException: jboss.cmp:service=tablecache,ejbname=Memo,table=memo already registered.
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.add(BasicMBeanRegistry.java:761)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:225)
> 	at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1422)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1417)
> 	at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:376)
> 	at org.jboss.ejb.plugins.cmp.jdbc2.schema.EntityTable.<init>(EntityTable.java:211)
> 	... 67 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 04:25:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 13 Sep 2006 04:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
Message-ID: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>

Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
---------------------------------------------------------

                 Key: JBAS-3651
                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
             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 hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 04:45:44 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Wed, 13 Sep 2006 04:45:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30270443.1158137144041.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Nitzan Niv updated JBCACHE-765:
-------------------------------

    Attachment: CachedMapImpl.java
                CachedListAbstract.java

Attached are versions with fixed equals().
The fixed List implementation also contains a hashCode caculation as defined in the List Javadoc.

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: CachedListAbstract.java, CachedMapImpl.java
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 04:51:43 2006
From: jira-events at jboss.com (Nitzan Niv (JIRA))
Date: Wed, 13 Sep 2006 04:51:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5281842.1158137503919.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Nitzan Niv updated JBCACHE-765:
-------------------------------

    Attachment: CachedMapImpl.java
                CachedListAbstract.java

I'm attaching updated versions of the files that also handle correctly comparison to null.

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: CachedListAbstract.java, CachedListAbstract.java, CachedMapImpl.java, CachedMapImpl.java
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 05:55:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 05:55:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-315) Break locks for
	state transfer
Message-ID: <19059415.1158141343902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-315?page=all ]

Manik Surtani updated JBCACHE-315:
----------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.1.0)
          Affects: [Documentation (Ref Guide, User Guide, etc.)]
       Complexity: High

Targetting this for 2.0.0 rather than 2.1.0

> Break locks for state transfer
> ------------------------------
>
>                 Key: JBCACHE-315
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-315
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> State transfer needs to acquire a lock on the root to make sure all existing TXs have been completed. However, when a TX takes more time than the lock acquisition timeout, state transfer will fail.
> Therefore, we need to forcefully acquire the locks for the state transfer by force-releasing the existing locks, and rolling back all TXs that held those locks.
> This will ensure that state transfer always succeeds, at the expense of some rolled back TXs.
> We need to investigate how this works with optimistic locking

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 05:55:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 05:55:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-326) Create the concept
 of a
 "priority queue" to speed execution of certain remote method invocations
Message-ID: <29039493.1158141344052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-326?page=all ]

Manik Surtani updated JBCACHE-326:
----------------------------------

    Complexity: Medium
      Assignee: Vladimir Blagojevic  (was: Bela Ban)

Are we still doing this?  This is the concept of a separate 'processor' thread for state events.

> Create the concept of a "priority queue" to speed execution of certain remote method invocations
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-326
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-326
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0
>
>
> Change the handling of requests in JBossCache (another  interceptor on top of ReplicationInterceptor): 
> - Create 2 queues (of MethodCall objects), one thread for each queue 
> - The regular MethodCalls like put(), remove() etc go into the  default queue (A), where they are processed according to order (FIFO) 
> - The special calls like block(), _getState(), commit() or acks  for PREPARE/COMMIT calls go into the other (priority) queue (B),  these calls *CAN* be received out of sequence 
> - This way, an _getState() would always be processed and  would be able to (1) stop the processing of queue A and (2) force- release any locks held 
>   by on the tree.
> _ This way commit() calls can promptly release locks, without having to wait behind other prepare 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

        


From jira-events at jboss.com  Wed Sep 13 06:23:43 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 13 Sep 2006 06:23:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1034) prototype ldap
	in portal
Message-ID: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>

prototype ldap in portal
------------------------

                 Key: JBPORTAL-1034
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz


prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:25:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-328) Move attributes and
 getters/setters to interceptors
Message-ID: <19987850.1158143143939.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-328?page=all ]

Manik Surtani closed JBCACHE-328.
---------------------------------

    Resolution: Won't Fix

A different approach is used instead.  Cache-wide configuration is encapsulated in a Configuration object, which is injected into each of the interceptors.  

This way the config can be managed independent of the interceptors.

> Move attributes and getters/setters to interceptors
> ---------------------------------------------------
>
>                 Key: JBCACHE-328
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-328
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> Example: currently IsolationLevel is an attribute of TreeCache. Goal is to make it an attribute of PessimisticLockingInterceptor.
> Advantage:no unneeded methods in TreeCache, cluttering up the TreeCache class
> #1 Implicit Configuration (conceptual)
> --------------------
> <TreeCache>
>    <Replication>
>        <config> ... </config>
>        <mode>ASYNC</mode>
>     </Replication>
>     <IsolationLevel>
>          REPEATABLE-READ
>      </IsolationLevel>
> </TreeCache>
> This configures the interceptor chain
> #2 Explicit configuration
> ------------------------------------
> <TreeCache>
>    <Interceptor name="PessimisticLockingInterceptor"
>                      class="xxxx"
>                       level="REPEATABLE-READ" />
>     <Interceptor>...</Interceptor>
> </TreeCache>
> The chain is defined explicitly, attributes are defines per interceptor
> #3 JMX
> If JMx is used, JBossCache is registered with the MBeanServer, and all interceptors are registered under JBossCache, e.g.
> type=cache;name=JBossCache1
> type=cache;name=JBossCache1;interceptor_name=PessimisticLockingInterceptor
> type=cache;name=JBossCache1;interceptor_name=CacheLoaderInterceptor
> type=cache;name=JBossCache1;interceptor_name=ReplicationInterceptor
> #4 Programmatic access
> Can be done through JMX, but is not nice
> cache.getIsolationLevel() --> ((PessimisticLockingInterceptor)cache.getInterceptor("PessimisticLockingInterceptor")).getIsolationLevel()

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-692) UPdate unit tests
 to use new interfaces
In-Reply-To: <16805200.1152789131289.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17698756.1158143144020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-692?page=all ]

Manik Surtani closed JBCACHE-692.
---------------------------------

    Resolution: Done

> UPdate unit tests to use new interfaces
> ---------------------------------------
>
>                 Key: JBCACHE-692
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-692
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-768) Finalise JMX
 interface for Cache
Message-ID: <20732681.1158143144092.JavaMail.jira@cloud.prod.atl2.jboss.com>

Finalise JMX interface for Cache
--------------------------------

                 Key: JBCACHE-768
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-768
             Project: JBoss Cache
          Issue Type: Sub-task
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-768) Finalise JMX
 interface for Cache
In-Reply-To: <20732681.1158143144092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14804028.1158143144169.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-768?page=all ]

Manik Surtani updated JBCACHE-768:
----------------------------------

               Complexity: Medium
                  Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial, Compatibility/Configuration]
    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971235#3971235

> Finalise JMX interface for Cache
> --------------------------------
>
>                 Key: JBCACHE-768
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-768
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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

        


From jira-events at jboss.com  Wed Sep 13 06:25:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:25:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-768) Finalise JMX
 interface for Cache
In-Reply-To: <20732681.1158143144092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13303733.1158143144239.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-768?page=all ]

Manik Surtani updated JBCACHE-768:
----------------------------------

    Fix Version/s: 2.0.0

> Finalise JMX interface for Cache
> --------------------------------
>
>                 Key: JBCACHE-768
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-768
>             Project: JBoss Cache
>          Issue Type: Sub-task
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.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

        


From jira-events at jboss.com  Wed Sep 13 06:37:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:37:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-767) Fail more silently
 when setting node versions
In-Reply-To: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23881614.1158143863828.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]

Manik Surtani updated JBCACHE-767:
----------------------------------

    Fix Version/s: 2.0.0
                   1.4.0.SP2

Thanks for this patch

> Fail more silently when setting node versions
> ---------------------------------------------
>
>                 Key: JBCACHE-767
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>         Attachments: jbosscache-fail-more-silently-20060912.patch
>
>
> Hibernate's OptimisticTreeCache.writeUpdate does:
>                         Option option = new Option();
>                         option.setFailSilently( true );
>                         option.setDataVersion( NonLockingDataVersion.INSTANCE );
>                         cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
> Which you would expect would remove the item if it exists, while setting the data version,
> and silently do nothing otherwise. But it ends up, logging at level INFO:
> 12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
> java.lang.NullPointerException
>         at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
>         at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
>         at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
>         at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
> There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
> too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
> problem.
> What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
> setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:39:43 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 13 Sep 2006 06:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23972499.1158143983837.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=comments#action_12343240 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1034:
-----------------------------------------------

apacheDS is badly documented. This makes life much easier for embedding it:
http://docs.safehaus.org/display/APACHEDS/Embedding+ApacheDS
http://docs.safehaus.org/pages/viewpage.action?pageId=4982
and especially this:
https://svn.safehaus.org/repos/sandbox/apachecon/ldap/src/main/java/apachecon/ldap/LdapExposingApplication.java



> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>
> prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:39:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:39:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-767) Fail more silently
 when setting node versions
In-Reply-To: <28883589.1158085472888.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27514075.1158143983965.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-767?page=all ]

Manik Surtani closed JBCACHE-767.
---------------------------------

    Resolution: Done

> Fail more silently when setting node versions
> ---------------------------------------------
>
>                 Key: JBCACHE-767
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-767
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2, 2.0.0
>
>         Attachments: jbosscache-fail-more-silently-20060912.patch
>
>
> Hibernate's OptimisticTreeCache.writeUpdate does:
>                         Option option = new Option();
>                         option.setFailSilently( true );
>                         option.setDataVersion( NonLockingDataVersion.INSTANCE );
>                         cache.remove( new Fqn( regionFqn, key ), "ITEM", option );
> Which you would expect would remove the item if it exists, while setting the data version,
> and silently do nothing otherwise. But it ends up, logging at level INFO:
> 12:55:38,360 INFO  [org.jboss.cache.interceptors.TxInterceptor] (http-127.0.0.1-8080-1): There was a problem handling this request
> java.lang.NullPointerException
>         at org.jboss.cache.interceptors.OptimisticNodeInterceptor.invoke(OptimisticNodeInterceptor.java:68)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:84)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticCreateIfNotExistsInterceptor.invoke(OptimisticCreateIfNotExistsInterceptor.java:69)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticValidatorInterceptor.invoke(OptimisticValidatorInterceptor.java:75)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticLockingInterceptor.invoke(OptimisticLockingInterceptor.java:122)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.OptimisticReplicationInterceptor.invoke(OptimisticReplicationInterceptor.java:136)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
>         at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
>         at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
>         at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
>         at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5530)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3742)
>         at org.jboss.cache.TreeCache.remove(TreeCache.java:3297)
>         at org.hibernate.cache.OptimisticTreeCache.writeLoad(OptimisticTreeCache.java:76)
> There are some differences of opinion as to what should be logged at level INFO, but that's pretty clearly
> too much and too scary looking. My assumption is that any NullPointerException in the logs is a serious 
> problem.
> What the attached patch does is if the failSiliently option is set and the node doesn't exist, just skip
> setting the version. If failSilenlty isn't set, then it throws a CacheException rather than the current
> NullPointerException.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:49:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:49:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <438840.1158144583912.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani updated JBCACHE-766:
----------------------------------

    Fix Version/s: 1.4.0.SP2
                   2.0.0

Hacky, agreed, but effective.  :-)

In fact, I think this (as a concept) should be integrated to JBCACHE-752 (and I will x-reference accordingly) but for the 1.4.0 series, this patch can be introduced without breaking compatibility.

Extending the patch to cover remove(fqn, key) as well.

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:49:44 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:49:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30042871.1158144584022.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani updated JBCACHE-766:
----------------------------------

    Fix Version/s:     (was: 2.0.0)

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:53:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-752) Look into using
 JBC Marshaller implementations for responses as well as requests
In-Reply-To: <13898767.1156863079702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12393485.1158144823788.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12343243 ] 
            
Manik Surtani commented on JBCACHE-752:
---------------------------------------

See JBCACHE-766.

Some methods - put(fqn, key, value) and remove(fqn, key) - return the old value of the attribute.  Thi sreturn value is only used in the "local" version of the method.  The return value is not used in "remote" versions.  

Returning nulls for these (if remote) will simplify classloading and improve marshalling (of return values) performance, and reduce network traffic.

> Look into using JBC Marshaller implementations for responses as well as requests
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-752
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-752
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.0.0
>
>
> In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was added.  At some point JGroups may require that the *same* marshaller instance handle both.  JBC's current marshallers can't do this; need to look into what it would take to do it.
> Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for RPC based state transfer).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 06:59:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 06:59:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-766) Don't return
 unnecessary values from _replicate, avoiding need for marshalling
In-Reply-To: <10595932.1158079300228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33239127.1158145183832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-766?page=all ]

Manik Surtani closed JBCACHE-766.
---------------------------------

    Resolution: Done

Thanks for the patch

> Don't return unnecessary values from _replicate, avoiding need for marshalling
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-766
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-766
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>         Attachments: jbosscache-avoid-return-20060912.patch
>
>
> This is somewhat related to JBCACHE-752, which suggests setting a marshaller for
> responses passed over RpcDispatcher as well as for requests, but is a simpler and
> less general fix.
> Right now if you set a class loader for a tree cache region, it works for request parameters,
> but is ignored for returns. If there is an attempt to return a value that needs to be loaded
> with the class loader, an exception will be thrown.
> The only return value in normal REPL_SYNC operation is the return value from 
> the key-value put methods, which is the old value, if any. But that return value isn't
> needed for replication. So, this patch just nulls out the return value from the two affected
> methods.
> (We're setting a class loader to deal with the fact that enumerations fields of Hibernate 
> entities are stored directly in the cache, and are serialized/deserialized on replication.
> There's a JIRA entry for that issue, which likely should be fixed in Hibernate by storing
> such fields as ordinals, but I think this patch is a legitimate TreeCache fix, if done in a slightly 
> hacky manner.)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 07:01:43 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 07:01:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-752) Look into using
 JBC Marshaller implementations for responses as well as requests
In-Reply-To: <13898767.1156863079702.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23161040.1158145303786.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-752?page=comments#action_12343245 ] 
            
Manik Surtani commented on JBCACHE-752:
---------------------------------------

Note that JBCACHE-766 was only applied to the 1.4.0 branch - not the 2.0.0 one

> Look into using JBC Marshaller implementations for responses as well as requests
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-752
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-752
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Replication
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.0.0
>
>
> In JGroups 2.4 the ability to use a Marshaller for responses as well as requests was added.  At some point JGroups may require that the *same* marshaller instance handle both.  JBC's current marshallers can't do this; need to look into what it would take to do it.
> Should be simple, as RPC responses in JBC are either null, an exception, or a byte[] (for RPC based state transfer).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 07:17:43 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 07:17:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-490) All nodes to only
 have mandatory fields defined
Message-ID: <4039278.1158146263875.JavaMail.jira@cloud.prod.atl2.jboss.com>

All nodes to only have mandatory fields defined
-----------------------------------------------

                 Key: JBRULES-490
                 URL: http://jira.jboss.com/jira/browse/JBRULES-490
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 07:22:24 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 07:22:24 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-490) All nodes to
 only have mandatory fields defined
In-Reply-To: <4039278.1158146263875.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7362379.1158146544377.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-490?page=comments#action_12343246 ] 
            
Michael Neale commented on JBRULES-490:
---------------------------------------

should be able to make it like nt:undefined so we don't have to migrate if there are new fields added.

> All nodes to only have mandatory fields defined
> -----------------------------------------------
>
>                 Key: JBRULES-490
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-490
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:05:43 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:05:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-314) Integrate handling of
 block()/blockOk() into Multiplexer
Message-ID: <30162259.1158149143820.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate handling of block()/blockOk() into Multiplexer
--------------------------------------------------------

                 Key: JGRP-314
                 URL: http://jira.jboss.com/jira/browse/JGRP-314
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


Currently, blocks are not passed up to the Multiplexer, and the MuxChannel's blockOk() method is a no-op

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:07:44 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12361905.1158149264009.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Tim Fox updated JBMESSAGING-541:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                       (was: 1.0.1.CR5)
                   1.0.1.GA

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.0.1.GA
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Wed Sep 13 08:07:44 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:07:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <10783372.1158149264219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Tim Fox updated JBMESSAGING-207:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:10:39 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:10:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-92) Integrate and
 enable multiplex transport
Message-ID: <26967733.1158149439261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-92?page=all ]

Tim Fox updated JBMESSAGING-92:
-------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Integrate and enable multiplex transport
> ----------------------------------------
>
>                 Key: JBMESSAGING-92
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-92
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Replace "Connector per Consumer" solution with a Remoting UIL2-like transport
> The ConsumerInterceptor creates a new Connector instance per each Consumer, and associates maintains a reference to it as transitory metadata, so it can shut it down when the Consumer closes. 
> The Connector is necessary as a callback server for asynchronous notifications. The MessageCallbackHandler instance is registered to it. Maintaining an instance per Consumer is necessary to avoid port conflicts.
> This is a temporary solution until JBoss Remoting gets an UIL2-like transport.
> As long as we maintain a server socket per consumer, it won't be possbile to receive asynchronous notifications over firewalls.
> until multiplex performance is better it should not be the default tranport but should be available nevertheless

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:10:39 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:10:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-455) CVS to SVN
 repository migration
In-Reply-To: <2712491.1154459591320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24870613.1158149439367.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-455?page=all ]

Tim Fox updated JBMESSAGING-455:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> CVS to SVN repository migration
> -------------------------------
>
>                 Key: JBMESSAGING-455
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-455
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:12:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:12:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-199) Fix or mothball
 remotetopic
 so it does not require multiple deliveries per message reference
Message-ID: <1477229.1158149555290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ]

Tim Fox closed JBMESSAGING-199.
-------------------------------

    Resolution: Won't Fix

Remote Topic no longer exists in HEAD with new clustering code

> Fix or mothball remotetopic so it does not require multiple deliveries per message reference
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-199
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>
> Re-implement remote topic to be a router with multiple channels - one per peer.
> This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:12:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:12:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-228) Re-enable
 DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()
Message-ID: <25636677.1158149555504.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ]

Tim Fox closed JBMESSAGING-228.
-------------------------------

      Assignee: Tim Fox  (was: Ovidiu Feodorov)
    Resolution: Won't Fix

Old distributed tests are no longer relevant since we no longer use the old clustering code base

> Re-enable DistributedTopicTest testDistributedTopic_2() and  testDistributedTopic_4()
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-228
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and  testDistributedTopic_4(()
> because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run.
> Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:14:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-267) Re-enable
	distributed tests
Message-ID: <29102012.1158149673559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ]

Tim Fox closed JBMESSAGING-267.
-------------------------------

      Assignee: Tim Fox
    Resolution: Won't Fix

These tests are no longer relevant since they test the old clustering code base which is no longer used

> Re-enable distributed tests
> ---------------------------
>
>                 Key: JBMESSAGING-267
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0.
> These tests should be re-enabled and adjusted as necessary for the 1.2 release.
> All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:14:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:14:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-404) Remove
 Channel::deliver(Receiver r) method
Message-ID: <14667824.1158149673686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ]

Tim Fox closed JBMESSAGING-404.
-------------------------------

    Resolution: Done

With the new push style of delivery, this method no longer exists

> Remove Channel::deliver(Receiver r) method
> ------------------------------------------
>
>                 Key: JBMESSAGING-404
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This method is used to effectively do a synchronous receive() on a channel.
> The functionality could be more simply implemented by doing adding a MessageReference receive() method.
> This would also help in a clustered environment since we would have one less network RPC.
> Most of the complexity here is in updating tests.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:16:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:16:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <19089706.1158149795983.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Tim Fox updated JBMESSAGING-431:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ron Sigal
>             Fix For: 1.2.0.Beta1
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:16:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:16:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-467) Sort out JBoss
 AS dependencies
In-Reply-To: <9629814.1154476211339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9709195.1158149796112.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-467?page=all ]

Tim Fox updated JBMESSAGING-467:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Sort out JBoss AS dependencies
> ------------------------------
>
>                 Key: JBMESSAGING-467
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-467
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>
> Currently we've imported JBossAS in the lib area of our project to keep the project compiling. This is hardly an acceptable solution. The proper solution involves:
> 1) Deciding what JBossAS depenencies we need and getting rid of artificially introduced dependencies
> 2) Work with AS team to identifiy the AS interfaces that need to be isolated and exposed in the repository.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:16:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:16:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <9702429.1158149796264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Tim Fox closed JBMESSAGING-361.
-------------------------------

    Resolution: Done

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:18:40 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:18:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-468) Re-activate
 the perf framework under the new build system
In-Reply-To: <20185700.1154476571322.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18560378.1158149920233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-468?page=all ]

Tim Fox updated JBMESSAGING-468:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Re-activate the perf framework under the new build system
> ---------------------------------------------------------
>
>                 Key: JBMESSAGING-468
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-468
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>
> Make sure perf framework works correctly
> Find the right location for       
> <path location="../src/resources/jcommon-1.0.0-rc1.jar"/>
>  <path location="../src/resources/jfreechart-1.0.0-rc1.jar"/>
> Also, restore    <!-- <ant dir="./perf" antfile="build.xml" inheritAll="false" target="clean"/> --> in build-messaging.xml and understand why it tries to delete svn/thirdparty/libraries.ent

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:18:40 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:18:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-192) Refactor
 Replicator so it
 won't be forced to provide noop implementation for Distributor's methods.
Message-ID: <32826551.1158149920385.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ]

Tim Fox closed JBMESSAGING-192.
-------------------------------

    Resolution: Won't Fix
      Assignee: Tim Fox  (was: Ovidiu Feodorov)

Replicator no longer exists in new clustering code base

> Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-192
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR2 (clustered)
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for
> Set handle(DeliveryObserver observer, Routable routable, Transaction transaction)
> However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport  implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor.
> Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:20:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:20:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-200) Complete XA
 transaction recovery
Message-ID: <1816773.1158150034207.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ]

Tim Fox closed JBMESSAGING-200.
-------------------------------

    Resolution: Duplicate Issue

Duplicate of 407

> Complete XA transaction recovery
> --------------------------------
>
>                 Key: JBMESSAGING-200
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Complete XA transaction recovery.
> Most of the work is already in place for this.
> The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery.
> The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager.
> We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:22:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:22:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-332) Consider how
 best to factor paging logic out of channel state
Message-ID: <22468492.1158150154230.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ]

Tim Fox closed JBMESSAGING-332.
-------------------------------

    Resolution: Done

Now abstracted out into PagingChannel

> Consider how best to factor paging logic out of channel state
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-332
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete 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

        


From jira-events at jboss.com  Wed Sep 13 08:24:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:24:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-315) Create check list of
	manual tests
Message-ID: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create check list of manual tests
---------------------------------

                 Key: JGRP-315
                 URL: http://jira.jboss.com/jira/browse/JGRP-315
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.5


Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
- JGroups/doc/tests/GmsTests.txt
- Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:24:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:24:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-310) Investigate
 whether rw lock on ServerConnectionEndpoint is necessary
Message-ID: <13343952.1158150273601.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ]

Tim Fox closed JBMESSAGING-310.
-------------------------------

    Resolution: Done

It's been removed

> Investigate whether rw lock on ServerConnectionEndpoint is necessary
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-310
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:26:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-422) Move channel
 mapper logic into Queue, Topic, Subscription classes
Message-ID: <28676861.1158150393292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ]

Tim Fox closed JBMESSAGING-422.
-------------------------------

    Resolution: Done

These classes no longer exist

> Move channel mapper logic into Queue, Topic, Subscription classes
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-422
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes.
> It's currently a bit of a mess.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:26:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-435) PointToPoint
 delivery with multiple consumers and selectors is broken
In-Reply-To: <23154601.1152954191989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1325853.1158150393432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-435?page=all ]

Tim Fox closed JBMESSAGING-435.
-------------------------------

    Resolution: Done

> PointToPoint delivery with multiple consumers and selectors is broken
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-435
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery.
> If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer.
> Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:28:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:28:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-414) Simplify
	delivery hierarchy
Message-ID: <11740785.1158150512362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox closed JBMESSAGING-414.
-------------------------------

    Resolution: Done

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:28:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:28:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-425) Naming of Pipe
 and Distributed Pipe
Message-ID: <596150.1158150512498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox closed JBMESSAGING-425.
-------------------------------

      Assignee: Tim Fox
    Resolution: Won't Fix

These classes no longer exist

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:30:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:30:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <20635233.1158150633982.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox closed JBMESSAGING-197.
-------------------------------

    Resolution: Done
      Assignee: Tim Fox  (was: Ovidiu Feodorov)

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:30:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <24630983.1158150634154.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox reassigned JBMESSAGING-269:
-----------------------------------

    Assignee: Tim Fox

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:30:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:30:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <16301779.1158150634309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox closed JBMESSAGING-269.
-------------------------------

    Resolution: Done

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <15729464.1158150752890.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox reopened JBMESSAGING-269:
---------------------------------

             

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <30570684.1158150753045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox updated JBMESSAGING-269:
--------------------------------

    Fix Version/s:     (was: 1.2.1)
                   1.2.0.Alpha1

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <645640.1158150753219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox closed JBMESSAGING-269.
-------------------------------

    Resolution: Done

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <12324762.1158150753347.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox reopened JBMESSAGING-197:
---------------------------------

             

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <26546106.1158150753477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox updated JBMESSAGING-197:
--------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.1)

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:32:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:32:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <13458993.1158150753593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox closed JBMESSAGING-197.
-------------------------------

    Resolution: Done

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-425) Naming of
 Pipe and Distributed Pipe
Message-ID: <31441783.1158150871521.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox reopened JBMESSAGING-425:
---------------------------------

             

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-425) Naming of Pipe
 and Distributed Pipe
Message-ID: <32232880.1158150871622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox closed JBMESSAGING-425.
-------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.1)
       Resolution: Done

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-414) Simplify
 delivery hierarchy
Message-ID: <27584630.1158150871733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox reopened JBMESSAGING-414:
---------------------------------

             

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:34:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:34:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-414) Simplify
	delivery hierarchy
Message-ID: <24301907.1158150871853.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox closed JBMESSAGING-414.
-------------------------------

    Fix Version/s: 1.2.0.Alpha1
    Fix Version/s:     (was: 1.2.1)
       Resolution: Done

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-192) Refactor
 Replicator so it
 won't be forced to provide noop implementation for Distributor's methods.
Message-ID: <27634439.1158151111542.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ]

Tim Fox reopened JBMESSAGING-192:
---------------------------------

             

> Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-192
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR2 (clustered)
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for
> Set handle(DeliveryObserver observer, Routable routable, Transaction transaction)
> However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport  implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor.
> Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <33414445.1158151111680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox reopened JBMESSAGING-197:
---------------------------------

             

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:31 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-199) Fix or
 mothball
 remotetopic so it does not require multiple deliveries per message
 reference
Message-ID: <19020182.1158151111815.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ]

Tim Fox reopened JBMESSAGING-199:
---------------------------------

      Assignee: Tim Fox  (was: Ovidiu Feodorov)
             

> Fix or mothball remotetopic so it does not require multiple deliveries per message reference
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-199
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Re-implement remote topic to be a router with multiple channels - one per peer.
> This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-200) Complete XA
 transaction recovery
Message-ID: <9179614.1158151112082.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ]

Tim Fox reopened JBMESSAGING-200:
---------------------------------

             

> Complete XA transaction recovery
> --------------------------------
>
>                 Key: JBMESSAGING-200
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Complete XA transaction recovery.
> Most of the work is already in place for this.
> The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery.
> The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager.
> We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-228) Re-enable
 DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()
Message-ID: <22796986.1158151112262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ]

Tim Fox reopened JBMESSAGING-228:
---------------------------------

             

> Re-enable DistributedTopicTest testDistributedTopic_2() and  testDistributedTopic_4()
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-228
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and  testDistributedTopic_4(()
> because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run.
> Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-267) Re-enable
 distributed tests
Message-ID: <24494659.1158151112371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ]

Tim Fox reopened JBMESSAGING-267:
---------------------------------

             

> Re-enable distributed tests
> ---------------------------
>
>                 Key: JBMESSAGING-267
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0.
> These tests should be re-enabled and adjusted as necessary for the 1.2 release.
> All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <11074791.1158151112575.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox reopened JBMESSAGING-269:
---------------------------------

             

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-310) Investigate
 whether rw lock on ServerConnectionEndpoint is necessary
Message-ID: <28440246.1158151112774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ]

Tim Fox reopened JBMESSAGING-310:
---------------------------------

             

> Investigate whether rw lock on ServerConnectionEndpoint is necessary
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-310
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-332) Consider how
 best to factor paging logic out of channel state
Message-ID: <29443384.1158151112928.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ]

Tim Fox reopened JBMESSAGING-332:
---------------------------------

             

> Consider how best to factor paging logic out of channel state
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-332
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete 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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <28560559.1158151113164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Tim Fox reopened JBMESSAGING-361:
---------------------------------

             

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-404) Remove
 Channel::deliver(Receiver r) method
Message-ID: <8853461.1158151113296.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ]

Tim Fox reopened JBMESSAGING-404:
---------------------------------

             

> Remove Channel::deliver(Receiver r) method
> ------------------------------------------
>
>                 Key: JBMESSAGING-404
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This method is used to effectively do a synchronous receive() on a channel.
> The functionality could be more simply implemented by doing adding a MessageReference receive() method.
> This would also help in a clustered environment since we would have one less network RPC.
> Most of the complexity here is in updating tests.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-414) Simplify
 delivery hierarchy
Message-ID: <5163810.1158151113447.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox reopened JBMESSAGING-414:
---------------------------------

             

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-422) Move channel
 mapper logic into Queue, Topic, Subscription classes
Message-ID: <11416824.1158151113563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ]

Tim Fox reopened JBMESSAGING-422:
---------------------------------

             

> Move channel mapper logic into Queue, Topic, Subscription classes
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-422
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes.
> It's currently a bit of a mess.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-425) Naming of
 Pipe and Distributed Pipe
Message-ID: <167095.1158151113688.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox reopened JBMESSAGING-425:
---------------------------------

             

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:38:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-435) PointToPoint
 delivery with multiple consumers and selectors is broken
In-Reply-To: <23154601.1152954191989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14420618.1158151113834.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-435?page=all ]

Tim Fox reopened JBMESSAGING-435:
---------------------------------

             

> PointToPoint delivery with multiple consumers and selectors is broken
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-435
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.1
>
>
> The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery.
> If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer.
> Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:38:34 2006
From: jira-events at jboss.com (Michael Steiner (JIRA))
Date: Wed, 13 Sep 2006 08:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-351) method instance() in
 userPrincipal should be static
Message-ID: <29304742.1158151114106.JavaMail.jira@cloud.prod.atl2.jboss.com>

method instance() in userPrincipal should be static
---------------------------------------------------

                 Key: JBSEAM-351
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-351
             Project: JBoss Seam
          Issue Type: Patch
          Components: Core
    Affects Versions: 1.1
            Reporter: Michael Steiner
            Priority: Trivial




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Michael Steiner (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-351) method instance() in
 userPrincipal should be static
In-Reply-To: <29304742.1158151114106.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20936203.1158151234493.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-351?page=all ]

Michael Steiner updated JBSEAM-351:
-----------------------------------

    Attachment: patch.txt

add static before instance) method in userPrincipal component

> method instance() in userPrincipal should be static
> ---------------------------------------------------
>
>                 Key: JBSEAM-351
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-351
>             Project: JBoss Seam
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 1.1
>            Reporter: Michael Steiner
>            Priority: Trivial
>         Attachments: patch.txt
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-192) Refactor
 Replicator so it
 won't be forced to provide noop implementation for Distributor's methods.
Message-ID: <32537160.1158151234645.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-192?page=all ]

Tim Fox closed JBMESSAGING-192.
-------------------------------

    Resolution: Done

> Refactor Replicator so it won't be forced to provide noop implementation for Distributor's methods.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-192
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-192
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR2 (clustered)
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> A replicator doesn't really need to implement org.jboss.messaging.core.Router, since its receivers are remote. It only needs support for
> Set handle(DeliveryObserver observer, Routable routable, Transaction transaction)
> However, currently the easiest way to plug a Replicator into the ChannelSupport implementation is to declare it Router. Refractor this and split the Router interface (and ChannelSupport  implementation) in two distinct parts: MultiReceiver (or some other name) and Distributor.
> Look for UnsupportedOperationException in org.jboss.messaging.core.distributed.replicator.Replicator.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-197) Refactor
 Channel, Distributor etc so there is only one receiver per channel
Message-ID: <28134410.1158151234770.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-197?page=all ]

Tim Fox closed JBMESSAGING-197.
-------------------------------

    Resolution: Done

> Refactor Channel, Distributor etc so there is only one receiver per channel
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-197
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-197
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently channels, allow multiple receivers.
> This is unnecessary and adds extra complecity.
> There is no need for a channel to ever have more than one active delivery per message reference at any one time.
> Channel should be refactored to only have one receiver.
> This gives us a much smaller and simpler base building block.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-199) Fix or mothball
 remotetopic
 so it does not require multiple deliveries per message reference
Message-ID: <17722908.1158151234902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-199?page=all ]

Tim Fox closed JBMESSAGING-199.
-------------------------------

    Resolution: Done

> Fix or mothball remotetopic so it does not require multiple deliveries per message reference
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-199
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-199
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core Distributed Support
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Re-implement remote topic to be a router with multiple channels - one per peer.
> This means it is not necessary to store receiver id persistently and there is only one delivery per reference per channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-200) Complete XA
 transaction recovery
Message-ID: <28226519.1158151235152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-200?page=all ]

Tim Fox closed JBMESSAGING-200.
-------------------------------

       Resolution: Done
    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.0.Beta1)

> Complete XA transaction recovery
> --------------------------------
>
>                 Key: JBMESSAGING-200
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-200
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Complete XA transaction recovery.
> Most of the work is already in place for this.
> The remaining pars mainly revolve around integrating with Transaction Managers e.g. Arjuna (and maybe others!) so they can obtain a handle to the XAResource in order to carry out recovery.
> The mechanism for this is not specified and so will vary from Transaction Manager to transaction manager. We need to supply wrappers for each popular Transaction Manager.
> We also need to complete the tests for this. (Perhaps Arjuna already has some tests we can re-use?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-228) Re-enable
 DistributedTopicTest testDistributedTopic_2() and testDistributedTopic_4()
Message-ID: <6104190.1158151235324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-228?page=all ]

Tim Fox closed JBMESSAGING-228.
-------------------------------

    Resolution: Done

> Re-enable DistributedTopicTest testDistributedTopic_2() and  testDistributedTopic_4()
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-228
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-228
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> I have overridden org.jboss.test.messaging.core.distributed.topic.base.DistributedTopicTestBase's testDistributedTopic_2() and  testDistributedTopic_4(()
> because they don't match the current assumption that a Channel has only one receiver, and still we want a clean test run.
> Adjust tests accordingly and enable them when this assumption will be better wired into the core and DistributedTopic reviewed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-267) Re-enable
	distributed tests
Message-ID: <19242404.1158151235449.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-267?page=all ]

Tim Fox closed JBMESSAGING-267.
-------------------------------

    Resolution: Done

> Re-enable distributed tests
> ---------------------------
>
>                 Key: JBMESSAGING-267
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-267
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Distributed destination tests have been disabled until after the 1.0 release since it is time consuming to keep them working when 1.0 will not include distributed destinations and the implementation is likely to change anyway after 1.0.
> These tests should be re-enabled and adjusted as necessary for the 1.2 release.
> All tests in org.jboss.test.messaging.core.distributed and sub packages have been disabled.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-269) Review
 ChannelMapper interface for possible functionality separation
Message-ID: <1657819.1158151235623.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-269?page=all ]

Tim Fox closed JBMESSAGING-269.
-------------------------------

    Resolution: Done

> Review ChannelMapper interface for possible functionality separation
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-269
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-269
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Currently, ChannelMapper seem to cram two different sets of concerns (core channel to destination mapping and durable subscription management) under the same interface. Review the interface (and the implementation) in search for a better solution, possibly involving service separation (DurableSubscriptionStore and ChannelMapper).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-310) Investigate
 whether rw lock on ServerConnectionEndpoint is necessary
Message-ID: <29099168.1158151235746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-310?page=all ]

Tim Fox closed JBMESSAGING-310.
-------------------------------

    Fix Version/s:     (was: 1.2.1)
       Resolution: Done
    Fix Version/s: 1.2.0.Alpha1

> Investigate whether rw lock on ServerConnectionEndpoint is necessary
> --------------------------------------------------------------------
>
>                 Key: JBMESSAGING-310
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-310
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:35 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-332) Consider how
 best to factor paging logic out of channel state
Message-ID: <17888418.1158151235859.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-332?page=all ]

Tim Fox closed JBMESSAGING-332.
-------------------------------

       Resolution: Done
    Fix Version/s:     (was: 1.2.1)
                   1.2.0.Alpha1

> Consider how best to factor paging logic out of channel state
> -------------------------------------------------------------
>
>                 Key: JBMESSAGING-332
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-332
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Need to consider whether to make paging strategy pluggable and factor current implementation out into a concrete 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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <11449048.1158151236029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Tim Fox closed JBMESSAGING-361.
-------------------------------

    Resolution: Done

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-404) Remove
 Channel::deliver(Receiver r) method
Message-ID: <31145692.1158151236140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-404?page=all ]

Tim Fox closed JBMESSAGING-404.
-------------------------------

    Resolution: Done

> Remove Channel::deliver(Receiver r) method
> ------------------------------------------
>
>                 Key: JBMESSAGING-404
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-404
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> This method is used to effectively do a synchronous receive() on a channel.
> The functionality could be more simply implemented by doing adding a MessageReference receive() method.
> This would also help in a clustered environment since we would have one less network RPC.
> Most of the complexity here is in updating tests.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-414) Simplify
	delivery hierarchy
Message-ID: <28469463.1158151236260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-414?page=all ]

Tim Fox closed JBMESSAGING-414.
-------------------------------

    Resolution: Done

> Simplify delivery hierarchy
> ---------------------------
>
>                 Key: JBMESSAGING-414
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-414
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The current delivery hierarchy seems over complex.
> A delivery only ever comes from one Receiver so the all we need is a:
> Delivery interface
> and 
> SimpleDelivery implementation
> Methods like acknowledge(), cancel() should be in the Delivery interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-422) Move channel
 mapper logic into Queue, Topic, Subscription classes
Message-ID: <12827251.1158151236379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-422?page=all ]

Tim Fox closed JBMESSAGING-422.
-------------------------------

       Resolution: Done
    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.1)

> Move channel mapper logic into Queue, Topic, Subscription classes
> -----------------------------------------------------------------
>
>                 Key: JBMESSAGING-422
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-422
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Much of the logic in the channel mapper is very non OO and should be moved into it's appropriate places in the relevant Queue, Topic or Subscription classes.
> It's currently a bit of a mess.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-425) Naming of Pipe
 and Distributed Pipe
Message-ID: <10472306.1158151236508.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-425?page=all ]

Tim Fox closed JBMESSAGING-425.
-------------------------------

    Resolution: Done

> Naming of Pipe and Distributed Pipe
> -----------------------------------
>
>                 Key: JBMESSAGING-425
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-425
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> The "Pipe" instance is basically a reliable channel that forwards from input to output.
> However the "DistributedPipe" is not a channel at all and seems to be just an abstraction of a remote connection, so seems to have no relation whatsoever to a "Pipe".
> Suggestion is to rename these classes to something that makes a bit more sense and is less confusing.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:40:36 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-435) PointToPoint
 delivery with multiple consumers and selectors is broken
In-Reply-To: <23154601.1152954191989.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <194193.1158151236655.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-435?page=all ]

Tim Fox closed JBMESSAGING-435.
-------------------------------

       Resolution: Done
    Fix Version/s:     (was: 1.2.1)
    Fix Version/s: 1.2.0.Alpha1

> PointToPoint delivery with multiple consumers and selectors is broken
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-435
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-435
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR3
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> The temporary "hack" fix put in to address JBMESSAGING-275 also breaks point to point delivery.
> If there is a queue with multiple competing consumers with different selectors. If a messages doesn't match the first consumer but does match the second consumer, because it is "arrested" in the first consumer, then the point to point router does not try it with the second consumer.
> Instead of "hacking the hack" we should fix all of this properly when we do JBMESSAGING-275

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:42:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:42:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1160047.1158151353622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=all ]

Tim Fox updated JBMESSAGING-505:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:44:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:44:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-471) Set up a
 process to update messaging artifacts in repository
In-Reply-To: <16597753.1154477411320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16329387.1158151473733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-471?page=all ]

Tim Fox updated JBMESSAGING-471:
--------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.2.0.Beta1

> Set up a process to update messaging artifacts in repository
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-471
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-471
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ruel Loehr
>             Fix For: 1.2.0.Beta1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:44:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:44:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-264) Provide a
 mechanism to
 forward messages from one destination to another automatically
Message-ID: <7828318.1158151473885.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-264?page=all ]

Tim Fox updated JBMESSAGING-264:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> Provide a mechanism to forward messages from one destination to another automatically
> -------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-264
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-264
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Chris DeLashmutt
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>
> I have had requests for this feature many times.  Basically, people seem to want to be able to have a component in messaging that will automatically forward messages to another destination.  This destination could be in the same messaging server or some remote destination. I'm thinking that the process must either be a daemon or an MDB, and since JBossMsg will also be available standalone I'm thinking we make it an MBean.  Another KEY to making this work is the 2PC stuff from Arjuna which isn't there yet (to make the pop and the push transactional).

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:46:32 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:46:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-519) Transparent
	failover / HA
In-Reply-To: <21500267.1155575300585.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11318649.1158151592109.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-519?page=all ]

Tim Fox updated JBMESSAGING-519:
--------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> Transparent failover / HA
> -------------------------
>
>                 Key: JBMESSAGING-519
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-519
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Tim Fox
>             Fix For: 1.2.0.Beta1
>
>
> Implement fully transparent failover for JMS clients as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:52:34 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-543) Use a file
 based transaction logger instead of logging in the database
Message-ID: <4467615.1158151954233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use a file based transaction logger instead of logging in the database
----------------------------------------------------------------------

                 Key: JBMESSAGING-543
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-543
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.2.1


Currently we are logging prepared state transactions in the database.

Instead, we should utilise a tried and tested transaction logger for performance reasons.

We should evaluate both JBoss TS objectstore, and HOWL to take this role

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:52:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-316) Backport of JGRP-217
Message-ID: <18775035.1158151954355.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport of JGRP-217
--------------------

                 Key: JGRP-316
                 URL: http://jira.jboss.com/jira/browse/JGRP-316
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.2.9 SP3 (2.2.9.3)
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.2.9 SP4




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:52:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-317) Backport of JGRP 302
 to JGroups 2.2.9 SP4
Message-ID: <23776931.1158151954629.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport of JGRP 302 to JGroups 2.2.9 SP4
-----------------------------------------

                 Key: JGRP-317
                 URL: http://jira.jboss.com/jira/browse/JGRP-317
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.2.9 SP3 (2.2.9.3)
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.2.9 SP4




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:54:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:54:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-318) Backport of JGRP-304
 to JGroups 2.2.9 SP4
Message-ID: <32101279.1158152077277.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport of JGRP-304 to JGroups 2.2.9 SP4
-----------------------------------------

                 Key: JGRP-318
                 URL: http://jira.jboss.com/jira/browse/JGRP-318
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.2.9 SP3 (2.2.9.3)
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.2.9 SP4




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:56:33 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Wed, 13 Sep 2006 08:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-544) Use NBIO for
 connection model
Message-ID: <31643741.1158152193353.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use NBIO for connection model
-----------------------------

                 Key: JBMESSAGING-544
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-544
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
         Assigned To: Tim Fox
             Fix For: 1.2.1


For throughput and scalability we need to use a non blocking IO model to provide connections between jms clients and server.

Unfortunately the JBoss remoting model does not currently allows this.

We can either drive JBoss Remoting to support this model (may take some time)

Or write out own connection functionality - this could be fairly straightforward if we use tools such as Apache MINA.

This would also solve the problem of providing a functional and performant multiplex transport.

Essentially we need a bidirectional channel between jms client and server.  On either end bytes can be read or witten in a non blocking fashion.

On top of that we can introduce simple framing in order to provide multiplex functionality.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 08:56:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 08:56:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-316) Backport of JGRP-217
In-Reply-To: <18775035.1158151954355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11507267.1158152193491.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-316?page=all ]

Bela Ban resolved JGRP-316.
---------------------------

    Resolution: Done

> Backport of JGRP-217
> --------------------
>
>                 Key: JGRP-316
>                 URL: http://jira.jboss.com/jira/browse/JGRP-316
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9 SP3 (2.2.9.3)
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.2.9 SP4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:02:32 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 09:02:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-318) Backport of JGRP-304
 to JGroups 2.2.9 SP4
In-Reply-To: <32101279.1158152077277.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3800669.1158152552808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-318?page=all ]

Bela Ban resolved JGRP-318.
---------------------------

    Resolution: Done

> Backport of JGRP-304 to JGroups 2.2.9 SP4
> -----------------------------------------
>
>                 Key: JGRP-318
>                 URL: http://jira.jboss.com/jira/browse/JGRP-318
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9 SP3 (2.2.9.3)
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.2.9 SP4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:10:32 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 13 Sep 2006 09:10:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-317) Backport of JGRP 302
 to JGroups 2.2.9 SP4
In-Reply-To: <23776931.1158151954629.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10227408.1158153032769.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-317?page=all ]

Bela Ban resolved JGRP-317.
---------------------------

    Resolution: Done

> Backport of JGRP 302 to JGroups 2.2.9 SP4
> -----------------------------------------
>
>                 Key: JGRP-317
>                 URL: http://jira.jboss.com/jira/browse/JGRP-317
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.2.9 SP3 (2.2.9.3)
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.2.9 SP4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:30:32 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 09:30:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-491) add document node
	type
Message-ID: <5435645.1158154232373.JavaMail.jira@cloud.prod.atl2.jboss.com>

add document node type
----------------------

                 Key: JBRULES-491
                 URL: http://jira.jboss.com/jira/browse/JBRULES-491
             Project: JBoss Rules
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 09:32:32 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Wed, 13 Sep 2006 09:32:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-491) add document
	node type
In-Reply-To: <5435645.1158154232373.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25953520.1158154352912.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-491?page=comments#action_12343258 ] 
            
Michael Neale commented on JBRULES-491:
---------------------------------------

should allow storage and classification of rule spec documentation (as it is JCR, after all !).

> add document node type
> ----------------------
>
>                 Key: JBRULES-491
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-491
>             Project: JBoss Rules
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:26:41 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 13 Sep 2006 10:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1035) Integrate JSUnit
 with existing testing framework.
Message-ID: <24165503.1158157601048.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate JSUnit with existing testing framework.
-------------------------------------------------

                 Key: JBPORTAL-1035
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1035
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:38:36 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Wed, 13 Sep 2006 10:38:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-349) IssueTracker
 @LoggedIn missing @Interceptors annotation
In-Reply-To: <931519.1157705853664.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12927039.1158158316687.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-349?page=all ]

Stephan Bublava closed JBSEAM-349.
----------------------------------

    Resolution: Cannot Reproduce Bug

This works all right after all; I missed that there are two annotations that work together (@LoggedIn, @CheckLoggedIn)...

> IssueTracker @LoggedIn missing @Interceptors annotation
> -------------------------------------------------------
>
>                 Key: JBSEAM-349
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-349
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>
> I believe org.jboss.seam.example.issues.LoggedIn misses a @Interceptors(LoggedInInterceptor.class) annotation.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:42:40 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:42:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12684766.1158158560914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Ovidiu Feodorov updated JBMESSAGING-541:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.0.1.GA)

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Wed Sep 13 10:44:34 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:44:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <26014130.1158158674859.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.0.Beta1)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:46:38 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Wed, 13 Sep 2006 10:46:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-61) Apache Tomcat 6.0
In-Reply-To: <21194316.1153309331365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21321978.1158158798924.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-61?page=comments#action_12343265 ] 
            
Remy Maucherat commented on JBWEB-61:
-------------------------------------

The finalized API is now implemented, featuring filtering. Some more minor details are not implemented yet.

> Apache Tomcat 6.0
> -----------------
>
>                 Key: JBWEB-61
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-61
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Remy Maucherat
>         Assigned To: Remy Maucherat
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:46:39 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:46:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <30956432.1158158799083.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Ovidiu Feodorov updated JBMESSAGING-431:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.0.Beta1)

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ron Sigal
>             Fix For: 1.0.1.CR5
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:48:34 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <24633284.1158158914699.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-361:
-----------------------------------------

      Assignee: Ovidiu Feodorov  (was: Tim Fox)
             
I need to give it a litte bit more thought. I will close it myself.

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 10:48:34 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 10:48:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <288788.1158158914806.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov updated JBMESSAGING-361:
----------------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
                   1.0.1.CR5

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:28:40 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:28:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6647851.1158161320658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov updated JBMESSAGING-542:
----------------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:28:40 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:28:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-277) Setting
 remoting lease period to -1 breaks ASF
Message-ID: <4393264.1158161320880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-277?page=all ]

Ovidiu Feodorov updated JBMESSAGING-277:
----------------------------------------

         Assignee: Ron Sigal
    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.0.Alpha1)

> Setting remoting lease period to -1 breaks ASF
> ----------------------------------------------
>
>                 Key: JBMESSAGING-277
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-277
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> LeasePeriod == -1 is supposed to disable remoting leasing.
> However, setting LeasePeriod to -1 breaks ASF. TCK tests don't pass anymore.
> Whoever fixes this problem, should add a functional test so the Messaging testsuite catches this problem before TCK does.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:30:43 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:30:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <5987736.1158161443852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov updated JBMESSAGING-302:
----------------------------------------

    Fix Version/s:     (was: 1.2.0.Alpha1)
         Assignee: Clebert Suconic
    Fix Version/s: 1.0.1.CR5

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:30:44 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 13 Sep 2006 11:30:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-287)
 RemotingTest.testConnectionListener() invalid
Message-ID: <22527012.1158161444064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ]

Ovidiu Feodorov updated JBMESSAGING-287:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
         Assignee: Ron Sigal  (was: Tim Fox)
    Fix Version/s:     (was: 1.2.0.Alpha1)

> RemotingTest.testConnectionListener() invalid
> ---------------------------------------------
>
>                 Key: JBMESSAGING-287
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. 
> After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:55:34 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 11:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-3652) Add EULA to licenses
 folder of distribution
Message-ID: <33451974.1158162934873.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Ryan Campbell moved JBQA-465 to JBAS-3652:
------------------------------------------

    Project: JBoss Application Server  (was: JBoss QA)
        Key: JBAS-3652  (was: JBQA-465)

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Ryan Campbell
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:55:35 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 11:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3652) Add EULA to licenses
 folder of distribution
Message-ID: <2423287.1158162935060.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Ryan Campbell updated JBAS-3652:
--------------------------------

         Assignee: Rajesh Rajasekaran  (was: Ryan Campbell)
    Fix Version/s: JBossAS-4.0.5.GA

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 11:55:35 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 11:55:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3652) Add EULA to licenses
 folder of distribution
Message-ID: <5831114.1158162935219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Ryan Campbell updated JBAS-3652:
--------------------------------

    Priority: Critical  (was: Major)

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:07:34 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Wed, 13 Sep 2006 12:07:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-762) Configuration object
 enhancements
In-Reply-To: <17732187.1157804023738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21549443.1158163654392.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-762?page=all ]

Manik Surtani closed JBCACHE-762.
---------------------------------

      Assignee: Manik Surtani  (was: Hany Mesha)
    Resolution: Done

> Configuration object enhancements
> ---------------------------------
>
>                 Key: JBCACHE-762
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-762
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> 1.  Why isn't there a CacheFactory.createCache() (using the default configuration)
> 2.  I think it would be useful to have a static method in Configuration which returns the default config, so we could do: Cache c=new DefaultCacheFactory().createCache(Configuration.getDefault())
> 3.  Configuration should have a copy() or clone() method, so we can reuse a config, and make small modifications
> 4.  Make Configuration serializable (ship them around ?)

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:30:40 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Wed, 13 Sep 2006 12:30:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-348) IssueTracker
 example uses nonexisting annotation (Within)
In-Reply-To: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33230009.1158165040379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-348?page=all ]

Stephan Bublava updated JBSEAM-348:
-----------------------------------

    Attachment: jbseam-348-patch.txt

The attached patch fixes the build error.

> IssueTracker example uses nonexisting annotation (Within)
> ---------------------------------------------------------
>
>                 Key: JBSEAM-348
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>         Attachments: jbseam-348-patch.txt
>
>
> org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Wed Sep 13 12:36:35 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Wed, 13 Sep 2006 12:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <8125495.1158165395624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ]

Madhusudhan Konda updated JBMESSAGING-407:
------------------------------------------

    Attachment: xarecovery-patch.txt
                artifacts.zip

Please find the patch file with this message. I have also attached the compressed src and tests folders, just in case. 
Testing is something which I had a bit of problem - as to how to simulate the server crash etc. Please see the tests/build.xml where I descibed the testing process. I am sure you'll have issues :)
Thanks
Madhu

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:36:35 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Wed, 13 Sep 2006 12:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-352) debug.seam should
 be able to display interceptors for a given component
Message-ID: <27074460.1158165395733.JavaMail.jira@cloud.prod.atl2.jboss.com>

debug.seam should be able to display interceptors for a given component
-----------------------------------------------------------------------

                 Key: JBSEAM-352
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-352
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
    Affects Versions: 1.0.1
            Reporter: Stephan Bublava
            Priority: Trivial


It would be great, if debug.seam would display all interceptors that are enabled for a component. This just requires two getter methods for Component.interceptors and Component.clientSideInterceptors.

I can deliver a patch if desired...

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:38:40 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 13 Sep 2006 12:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-350) High conversation
 state number causes ui:repeat to show a single item
In-Reply-To: <852986.1157870850894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24397575.1158165520360.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-350?page=all ]

Gavin King closed JBSEAM-350.
-----------------------------

    Resolution: Rejected

Not a bug in Seam. (Facelets, maybe.)

> High conversation state number causes ui:repeat to show a single item
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-350
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-350
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>         Environment: CentOS i686, JDK 1.5.0_06-b05, MyFaces 1.1.3, Facelets 1.1.11, JBoss 4.0.4 with EJB3 RC8 FD
>            Reporter: Basel Al-Mustafa
>
> When the conversation state number goes up to around 4750 the ui:repeat element stops showing the compete list of items. Rather than that only a single item is displayed even though both of the database query and the SLSB page action return several items. The production server log and the source code can be found in the associated JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:38:40 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Wed, 13 Sep 2006 12:38:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <32423679.1158165520519.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12343270 ] 
            
Madhusudhan Konda commented on JBMESSAGING-407:
-----------------------------------------------

There has been additions to the *persistence.xml file. Have a look in the attached sybase-perisistence.xml

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 12:40:44 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 13 Sep 2006 12:40:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-598) add timeout config
 per client invocation
Message-ID: <29603001.1158165644827.JavaMail.jira@cloud.prod.atl2.jboss.com>

add timeout config per client invocation
----------------------------------------

                 Key: JBREM-598
                 URL: http://jira.jboss.com/jira/browse/JBREM-598
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
            Priority: Minor
             Fix For: 2.2.0.Beta1 (Bluto)


Would like to be able to control timeout per invocation.  Probably best way to do this is pass as part of metadata map passed to the invoke method within Client.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:06:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:06:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30861468.1158167199869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Scott M Stark updated JBAS-3650:
--------------------------------

    Attachment: jbosssx.jar

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:19:43 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:19:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
Message-ID: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
---------------------------------------------------------------------------------

                 Key: JBAS-3653
                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA
         Attachments: example2.ldif

For a schema like example2.ldif and a configuration like:
      testLdapExample22 {
         org.jboss.security.auth.spi.LdapExtLoginModule
            java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
            java.naming.provider.url="ldap://lamia/"
            java.naming.security.authentication=simple
            bindDN="cn=Root,dc=jboss,dc=org"
            bindCredential=secret1
            baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
            baseFilter="(uid={0})"
            rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
            roleFilter="(uid={0})"
            roleAttributeID="memberOf"
            roleAttributeIsDN="true"
            roleNameAttributeID="cn"
            roleRecursion=0
      };

Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:19:44 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:19:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14717137.1158167984059.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark updated JBAS-3653:
--------------------------------

    Attachment: example2.ldif

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:24:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:24:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9863809.1158168279422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark updated JBAS-3653:
--------------------------------

    Attachment:     (was: example2.ldif)

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:24:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:24:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3653) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7428488.1158168279532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark updated JBAS-3653:
--------------------------------

    Attachment: example2.ldif

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:24:39 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:24:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10020637.1158168279686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Scott M Stark updated JBAS-3650:
--------------------------------

    Attachment:     (was: jbosssx.jar)

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: JBoss QA Lead
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:29:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3112431.1158168581937.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Scott M Stark updated JBAS-3650:
--------------------------------

    Attachment: jbosssx.jar

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: JBoss QA Lead
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:43:33 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:43:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3653) Ldap*LoginModule fail
 to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <5589970.1158167983918.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29816080.1158169413801.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3653?page=all ]

Scott M Stark closed JBAS-3653.
-------------------------------

    Resolution: Done

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: JBAS-3653
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3653
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: example2.ldif
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the  cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:43:33 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 13:43:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-7) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
Message-ID: <7485782.1158169413906.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
---------------------------------------------------------------------------------

                 Key: SECURITY-7
                 URL: http://jira.jboss.com/jira/browse/SECURITY-7
             Project: JBoss Security
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: 2.0


For a schema like example2.ldif and a configuration like:
      testLdapExample22 {
         org.jboss.security.auth.spi.LdapExtLoginModule
            java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
            java.naming.provider.url="ldap://lamia/"
            java.naming.security.authentication=simple
            bindDN="cn=Root,dc=jboss,dc=org"
            bindCredential=secret1
            baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
            baseFilter="(uid={0})"
            rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
            roleFilter="(uid={0})"
            roleAttributeID="memberOf"
            roleAttributeIsDN="true"
            roleNameAttributeID="cn"
            roleRecursion=0
      };

Only one role is being pulled from the cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:43:34 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 13 Sep 2006 13:43:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-257) Test extender test
 in a scoped environment
Message-ID: <28967632.1158169414099.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-257?page=comments#action_12343272 ] 
            
Kabir Khan commented on JBAOP-257:
----------------------------------

Methods and fields now work - still need to test constructors

The tests do all compinations of

* Base, global sar with classes loaded/classes not loaded
* Child, scoped sar with parent delegation/no parent delegation

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 13:55:38 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 13:55:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2283) Custom header based
	authentication
Message-ID: <30256412.1158170138795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2283?page=all ]

Anil Saldhana closed JBAS-2283.
-------------------------------

    Resolution: Done

> Custom header based authentication
> ----------------------------------
>
>                 Key: JBAS-2283
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2283
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.CR1
>
>         Attachments: B19006.pdf, B19008v2.pdf, B19013.pdf
>
>
> We have been getting requests for custom authentication methods based around prorpietary headers/logic. The following attachments describe the oracle COREid product.
> B19006.pdf - high level overview of how the product works
> B19008v2.pdf - details of authentication protocol (p. 85 - 92)
> B19013.pdf - documentation about API
> Likely the most important part is assuming a user is who the HTTP_OBLIX_UID header says they are. The COREid server and the firewall should protect the server from unauthorized 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

        


From jira-events at jboss.com  Wed Sep 13 13:55:39 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 13:55:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2283) Custom header based
 authentication
Message-ID: <6182351.1158170139069.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2283?page=comments#action_12343273 ] 
            
Anil Saldhana commented on JBAS-2283:
-------------------------------------

$> ant tomcat-federation-tests
....
    [junit] Running org.jboss.test.web.security.CustomHeaderAuthTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.015 sec



> Custom header based authentication
> ----------------------------------
>
>                 Key: JBAS-2283
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2283
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.CR1
>
>         Attachments: B19006.pdf, B19008v2.pdf, B19013.pdf
>
>
> We have been getting requests for custom authentication methods based around prorpietary headers/logic. The following attachments describe the oracle COREid product.
> B19006.pdf - high level overview of how the product works
> B19008v2.pdf - details of authentication protocol (p. 85 - 92)
> B19013.pdf - documentation about API
> Likely the most important part is assuming a user is who the HTTP_OBLIX_UID header says they are. The COREid server and the firewall should protect the server from unauthorized 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

        


From jira-events at jboss.com  Wed Sep 13 14:07:37 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 13 Sep 2006 14:07:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-7) Ldap*LoginModule
 fail to retrieve multiple role names when roleAttributeIsDN=true
In-Reply-To: <7485782.1158169413906.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23562130.1158170857776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-7?page=all ]

Scott M Stark closed SECURITY-7.
--------------------------------

    Resolution: Done

> Ldap*LoginModule fail to retrieve multiple role names when roleAttributeIsDN=true
> ---------------------------------------------------------------------------------
>
>                 Key: SECURITY-7
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-7
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 2.0
>
>
> For a schema like example2.ldif and a configuration like:
>       testLdapExample22 {
>          org.jboss.security.auth.spi.LdapExtLoginModule
>             java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory
>             java.naming.provider.url="ldap://lamia/"
>             java.naming.security.authentication=simple
>             bindDN="cn=Root,dc=jboss,dc=org"
>             bindCredential=secret1
>             baseCtxDN="ou=People,o=example2,dc=jboss,dc=org"
>             baseFilter="(uid={0})"
>             rolesCtxDN="ou=Roles,o=example2,dc=jboss,dc=org";
>             roleFilter="(uid={0})"
>             roleAttributeID="memberOf"
>             roleAttributeIsDN="true"
>             roleNameAttributeID="cn"
>             roleRecursion=0
>       };
> Only one role is being pulled from the cn=EchoGroup,ou=Roles,o=example2,dc=jboss,dc=org context, rather the both EchoGroup and TheDuke as only one of the cn attribute values is retrieved. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:06:37 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Wed, 13 Sep 2006 16:06:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
Message-ID: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>

The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
----------------------------------------------------------------------------

                 Key: JBAS-3654
                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final,  JBossAS-4.0.3RC2,  JBossAS-4.0.3RC1
            Reporter: Sakthi Samabsivam
         Assigned To: Dimitris Andreadis


When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.

for example.  I have two ears example1. ear and example2.ear.

I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..

So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml

 <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>

This depends is working till jboss 4.0.1

It fails in 4.0.3 SP1 , 4.0.4 GA

15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
ment:war=crimeportal.war,id=-1360680885
org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
e: (javax.security.jacc.PolicyContextException: Operation not allowed)
        at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)

        at org.jboss.web.WebModule.startModule(WebModule.java:68)
        at org.jboss.web.WebModule.startService(WebModule.java:46)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:428)
        at org.jboss.system.ServiceController.start(ServiceController.java:446)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy21.start(Unknown Source)
        at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
        at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy9.deploy(Unknown Source)
        at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
tScanner.java:319)
        at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
canner.java:507)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
doScan(AbstractDeploymentScanner.java:192)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
bstractDeploymentScanner.java:265)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
upport.java:274)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
eanSupport.java:230)
        at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
ler.java:943)
        at $Proxy0.start(Unknown Source)
        at org.jboss.system.ServiceController.start(ServiceController.java:428)
        at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy4.start(Unknown Source)
        at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
        at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:141)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:118)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:127)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:245)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
        at org.jboss.Main.boot(Main.java:187)
        at org.jboss.Main$1.run(Main.java:438)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
        at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:201)
        at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
ossPolicyConfiguration.java:160)
        at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)

        ... 94 more
Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
tion: linkConfiguration from state:inService
        at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
        at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
olicyConfiguration.java:196)
        ... 96 more
15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:

--- MBeans waiting for other MBeans ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)

  I Depend On:
    jboss.j2ee:url='FiboApp.ear',service=EARDeployment

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
  State: FAILED
  Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)

  I Depend On:
    jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:42:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 16:42:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3655) Constructors in JMX
 AuthenticationInterceptor and AuthorizationInterceptor
Message-ID: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>

Constructors in JMX AuthenticationInterceptor and AuthorizationInterceptor
--------------------------------------------------------------------------

                 Key: JBAS-3655
                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMX, Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
	at java.lang.Class.getConstructor0(Class.java:2678)
	at java.lang.Class.getConstructor(Class.java:1629)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 

.....

2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
	at java.lang.Class.getConstructor0(Class.java:2678)
	at java.lang.Class.getConstructor(Class.java:1629)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:52:30 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 13 Sep 2006 16:52:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3656) Disconnect
 HAPartition channel upon failure in startService()
Message-ID: <12832750.1158180750351.JavaMail.jira@cloud.prod.atl2.jboss.com>

Disconnect HAPartition channel upon failure in startService()
-------------------------------------------------------------

                 Key: JBAS-3656
                 URL: http://jira.jboss.com/jira/browse/JBAS-3656
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1


If an exception is thrown in ClusterPartition/HAPartition startService() after the channel is connected, the channel must be disconnected, or we've left a zombie member of the group.  Particularly in 4.0.x where the ServiceController will not undeploy a service that fails in start().

Need to ensure stopService() properly handles a disconnected channel.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 16:58:32 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 16:58:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3336963.1158181112987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Anil Saldhana updated JBAS-3655:
--------------------------------

    Summary: Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker  (was: Constructors in JMX AuthenticationInterceptor and AuthorizationInterceptor)

It should be:
catch (Throwable t)
         {
            log.warn("Failed to invoke ctor(MBeanInvoker) for: "
               + interceptorClass, t); 
            // Try the default ctor
            interceptor = (Interceptor) interceptorClass.newInstance();
            log.warn("Success:default ctr used to construct:"+ interceptorClass);
         }

rather than log.debug

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:04:31 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 17:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25676936.1158181471720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Anil Saldhana updated JBAS-3655:
--------------------------------

    Fix Version/s:     (was: JBossAS-5.0.0.Beta)

Not applicable to HEAD.

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:04:31 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 13 Sep 2006 17:04:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28756764.1158181471858.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Anil Saldhana closed JBAS-3655.
-------------------------------

    Resolution: Done

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:22:34 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Wed, 13 Sep 2006 17:22:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <21333807.1158182554359.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343280 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Is this license used by any of the thirdparty libs, so they can be automatically pulled when downloading the thirdparty, by JBOSSBUILD.
If not i can upload to the repository and package it in the build output getting it directly from the repository.


> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:26:34 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 13 Sep 2006 17:26:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <29271369.1158182794714.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343281 ] 
            
Ryan Campbell commented on JBAS-3652:
-------------------------------------

For now, this is just for the AS itself, not libraries.  This should likely go in whatever module we keep the copyright.txt file, and be copied to docs/licenses in the build/build-dist.xml.

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:34:34 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 17:34:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1004) Jboss Portal to
 support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13926727.1158183274428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ]

Sverker Abrahamsson updated JBPORTAL-1004:
------------------------------------------

    Attachment: jboss-portal-2.4.patch

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 17:34:34 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 17:34:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1004) Jboss Portal to
 support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26562685.1158183274643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ]

Sverker Abrahamsson updated JBPORTAL-1004:
------------------------------------------

    Attachment: new.files.zip

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:12:31 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
Message-ID: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>

Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1036
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:12:31 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 18:12:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15105155.1158185551754.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343282 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

Ok, after a lot of working with the debugger and following the flow I've made the neccesary changes. It works beautifully now, if I may say it myself.

The attached patch and files are on the 2.4 branch but shouldn't bee too hard to port to head once we've agreed on a few design questions that needs to be discussed.

With this patch, if a war file contains an *-object.xml which creates a portal without any parent ref, then a new context is created and the virtual-host and context path settings of the war file is bound to it. The id of the context is either the application name given by jboss-app.xml or derived from the virtual-host and context path. I haven't updated Transient PortalObjectContainer yet with the new functionality, just added the method declarations to make it compile.

Next, after the deployment had been taken care of, the request processing had to change slightly. The servername is fetched from the request in PortalServlet and stored in ServletRequestContext. The CommandFactory classes are updated so that doMapping gets the portalHost parameter.

DefaultPortalCommandFactory caused a strange behaviour, if a link was wrong, e.g. spelled wrong or so, then it sent the request to the default portal. That resulted in that suddenly the default portal markup could appear in a middle of a page. I changed that so that if the CommandFactory chain failed to map the request, then a 404 response is sent via the new class ErrorResponseCommand. However, this more or less obsoletes this class. Instead CoreController should create a ErrorResponseCommand if cmd is null after passing through the CommandFactory chain.

DelegatingCommandFactoryService was modified to send a request to / to PortalObjectCommandFactory, it's doing that by shortcutting the PathParser but I think it's ok.

PortalObjectCommandFactory is modified to look up the context by using portalHost and portalContextPath. If a context can't be found using those data, then it tries to look up on just portalContextPath (for those cases where the webapp didn't specify any virual-host but just bind to the default name) and if still noting found then the default context is used.

CMSObjectCommandFactory was modified to send a ErrorResponseCommand with 404 if it couldn't find the file specified which is the correct behaviour. As it was before the default portal could suddenly appear in the middle of the page which looked quite strange. Also, it now respond with code 500 if an internal error occurs.

The same for StreamContentCommand. I noticed another thing, the file was first looked up in CMSObjectCommandFactory and then again in StreamContentCommand. I added a shortcut so that it could be passed along and hence eliminating the second lookup.

 A minor change had to be done on the security, in JACCPortalAuthorizationManager and JACCPortalAuthorizationManagerFactory as the configured roles have to be managed per context id (i.e. war file).

The last big change was on how theme is handled. Before it just rendered an url, e.g. /portal-core/themes/phalanx/portal_style.css which didnt work because that path didn't exsist in my virtual-host. Instead I created a new CommandFactory which is bound to /theme so if I have a portal bound to the url http://portaltest.abrahamsson.com which use theme Npalanx then the stylesheet is loaded from http://portaltest.abrahamsson.com/theme/themes/phalanx/portal_style.css 

Julien and Roy, please read through these proposed changes and let me know what you think.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:14:32 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:14:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22686411.1158185672206.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=comments#action_12343283 ] 
            
Julien Viet commented on JBPORTAL-1036:
---------------------------------------

we should probably use : org.jboss.portal.portlet.container. + class.getName().replace('.','_');

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.2.2 Final, 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:14:32 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 13 Sep 2006 18:14:32 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3649) Startup switches
 should set the new JGroups system properties
In-Reply-To: <13306029.1158112843780.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9087772.1158185672522.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3649?page=all ]

Brian Stansberry closed JBAS-3649.
----------------------------------

       Resolution: Done
    Fix Version/s: JBossAS-4.0.5.GA

Fixed for 4.0.5.GA as well.  That release ships with JGroups 2.2.7 which internally still only uses the old bind.address property.  But the -b switch will set both versions of the property, so if a user upgrades to JGroups 2.4 or higher or uses the new property in a config file, it will be respected.

> Startup switches should set the new JGroups system properties
> -------------------------------------------------------------
>
>                 Key: JBAS-3649
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3649
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> JGroups has created a more formalized system for the names of the system properties it uses (see http://wiki.jboss.org/wiki/Wiki.jsp?page=SystemProps).  We need to ensure that when the JBoss AS command-line switches are used, the new system properties get set:
> -b jgroups.bind_addr
> -u  jgroups.udp.mcast_addr
> The old properties will be set as well to ensure legacy config files still work.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:18:31 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:18:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31581100.1158185911045.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=all ]

Julien Viet reassigned JBPORTAL-1036:
-------------------------------------

    Assignee: Chris Laprun  (was: Julien Viet)

assigning it to the right person

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.2.2 Final, 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:18:30 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:18:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1033)
 PortletContainer added logging causes class loading issues.
In-Reply-To: <4364937.1158098671693.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14160142.1158185910878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1033?page=all ]

Julien Viet resolved JBPORTAL-1033.
-----------------------------------

    Resolution: Duplicate Issue

oops duplicate, I keep the other as the description is more detailled.

> PortletContainer added logging causes class loading issues.
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1033
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1033
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2.1 Final
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1
>
>
> In PortletContainer constructor:
> this.portletLog = Logger.getLogger(metaData.getClassName());
> causes Log4J to be loaded in several different class loaders causing CCEs.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:36:31 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Wed, 13 Sep 2006 18:36:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2131606.1158186991194.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343289 ] 
            
Julien Viet commented on JBPORTAL-1004:
---------------------------------------

Looking at it quickly, you need to provide a solution that does not require modifications of the PortalObject concepts.

Why not map virtual host to portal instead ?

The PortalObject : Context is supposed to be unique and the root of the portal object tree.


> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 18:36:31 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 13 Sep 2006 18:36:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7780323.1158186991301.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=comments#action_12343290 ] 
            
Chris Laprun commented on JBPORTAL-1036:
----------------------------------------

See also http://jira.jboss.com/jira/browse/JBPORTAL-1020

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.2.2 Final, 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:10:31 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 13 Sep 2006 19:10:31 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1037) Tool based
 mechanism (e.g. Eclipse plugin) for modifying portal metadata
Message-ID: <27943353.1158189031292.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tool based mechanism (e.g. Eclipse plugin) for modifying portal metadata
------------------------------------------------------------------------

                 Key: JBPORTAL-1037
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1037
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: William DeCoste
            Priority: Optional


This is a request from Intuit. I can gather more detailed requirements as needed - Bill

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:28:33 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 13 Sep 2006 19:28:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1038) Allow export of
 database to xml
Message-ID: <24585280.1158190113259.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allow export of database to xml
-------------------------------

                 Key: JBPORTAL-1038
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1038
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.4 Final
            Reporter: William DeCoste
            Priority: Minor


This feature was requested by Intuit.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:30:29 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 13 Sep 2006 19:30:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1038) Allow export
 of database to xml
In-Reply-To: <24585280.1158190113259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21483287.1158190229919.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1038?page=comments#action_12343292 ] 
            
William DeCoste commented on JBPORTAL-1038:
-------------------------------------------

They want to be able to move a configuration from one environment to another (development to test to production)

> Allow export of database to xml
> -------------------------------
>
>                 Key: JBPORTAL-1038
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1038
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final
>            Reporter: William DeCoste
>            Priority: Minor
>
> This feature was requested by Intuit.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 19:54:33 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Wed, 13 Sep 2006 19:54:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18512665.1158191673533.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343293 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

Well, the idea I had was that since a different web application is essentially a different context then create new contexts under the root would be the right way to go. If you have only one context then you can optimize it away, it doesn't add any value to the data model.

Not that it matters though, I think it should be possible to map ContextPath to Portal instead. The only issue I can think of from the top of my head is how to decide which is the default portal if several portals is deployed in the same *-object.xml without parent references but that can be handled by being a bit picky when deploying.

I don't really care which, the only thing I care about is the functionality in the end.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 21:22:29 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Wed, 13 Sep 2006 21:22:29 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-492) Debug views should
 remember if they are + or 1
Message-ID: <9721054.1158196949067.JavaMail.jira@cloud.prod.atl2.jboss.com>

Debug views should remember if they are + or 1
----------------------------------------------

                 Key: JBRULES-492
                 URL: http://jira.jboss.com/jira/browse/JBRULES-492
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 3.1-m1


When you are continually using the debug views its annoying to keep pressing the + to expand, it would be nice if it stayed expanded once it was selected.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 21:26:30 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Wed, 13 Sep 2006 21:26:30 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-493) Remember selected
 working memory for debug views
Message-ID: <26521911.1158197190038.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remember selected working memory for debug views
------------------------------------------------

                 Key: JBRULES-493
                 URL: http://jira.jboss.com/jira/browse/JBRULES-493
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Eclipse IDE
            Reporter: Mark Proctor
         Assigned To: Kris Verlaenen
             Fix For: 3.1-m1


When you select working memory it should remember that instance, so when you are propagating through the network you shouldn't have to keep re-selecting it to view data. Better yet we should have another debug view that collects working memory instances as it "realises" them during debug runtime, the current one is highlighed and a different current can easily be selected.

-- 
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

        


From jira-events at jboss.com  Wed Sep 13 22:53:43 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Wed, 13 Sep 2006 22:53:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-494) Linked Tuple
Message-ID: <15357564.1158202423100.JavaMail.jira@cloud.prod.atl2.jboss.com>

Linked Tuple
------------

                 Key: JBRULES-494
                 URL: http://jira.jboss.com/jira/browse/JBRULES-494
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1


Instead of cloning FactHandle['] arrays, which is expensive, as its creating factorial too many objects, we shoudl instead looked to some sort of linked list; so that it doesn't need to copy the information of the parents.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 00:37:36 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 14 Sep 2006 00:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-183) write release guide
Message-ID: <6529297.1158208656584.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-183?page=all ]

Alejandro Guizar updated BPEL-183:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 2)

> write release guide
> -------------------
>
>                 Key: BPEL-183
>                 URL: http://jira.jboss.com/jira/browse/BPEL-183
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> QA requires a release guide in the wiki area. Use http://wiki.jboss.org/wiki/Wiki.jsp?page=JbpmReleaseGuide as a template.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 00:37:36 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 14 Sep 2006 00:37:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-186) Write a blog entry
 about the beta release
Message-ID: <24862724.1158208656709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-186?page=all ]

Alejandro Guizar updated BPEL-186:
----------------------------------

          Summary: Write a blog entry about the beta release  (was: Write a blog entry about the 1.1 release)
    Fix Version/s: jBPM BPEL 1.1 beta 2
                       (was: jBPM BPEL 1.1 beta 3)

> Write a blog entry about the beta release
> -----------------------------------------
>
>                 Key: BPEL-186
>                 URL: http://jira.jboss.com/jira/browse/BPEL-186
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 02:05:38 2006
From: jira-events at jboss.com (Stephan Bublava (JIRA))
Date: Thu, 14 Sep 2006 02:05:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-353) @Interceptors
 meta-annotation needs @Target(TYPE)
Message-ID: <14552072.1158213938068.JavaMail.jira@cloud.prod.atl2.jboss.com>

@Interceptors meta-annotation needs @Target(TYPE)
-------------------------------------------------

                 Key: JBSEAM-353
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-353
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Documentation
    Affects Versions: 1.0.1
            Reporter: Stephan Bublava
            Priority: Minor


The @Interceptors meta-annotation only works with @Target(TYPE). If you want to intercept certain methods only, two cooperating annotations are required (as demonstrated by the issue tracker example in CVS, which uses @LoggedIn and @CheckLoggedIn).

Since this is not obvious (at least to me), it should be explained in the documentation (chapter 2.6. Seam interceptors).

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:41:37 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 03:41:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-16) scratchdir fails
 for multi-user installs
Message-ID: <32023555.1158219697540.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-16?page=comments#action_12343300 ] 
            
Luc Texier commented on JBWEB-16:
---------------------------------

I had to investigate this problem for a customer.

The issue is that the last folder at the end of the path is not created automatically. 

so if you want Tomcat to write to e.g. /home/myuser/jboss/work, /work must exist already


Note: If a path is not specified as in the default configuration, "something" is creating the "/work" directory...what? I dunno



> scratchdir fails for multi-user installs
> ----------------------------------------
>
>                 Key: JBWEB-16
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-16
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat Module
>    Affects Versions:  JBossWeb embedded - AS 4.0.1
>            Reporter: Norman Richards
>         Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8).   Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis.  Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. 
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:43:37 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 03:43:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <24208115.1158219817437.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Luc Texier updated JBAS-3641:
-----------------------------

    Security: Public  (was: JBoss Partner)

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:57:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 14 Sep 2006 03:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-313) MultiplexerTests
 don't work with TCP configuration
In-Reply-To: <15805211.1158066153671.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20140105.1158220657346.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-313?page=comments#action_12343301 ] 
            
Bela Ban commented on JGRP-313:
-------------------------------

They actually work with "tcp" (TCP), but there are failures in "tcp-nio" (TCP_NIO). Probably due to TCP_NIO not being stopped correctly in tearDown(), so that new tests conflict with leftover sockets from previous tests: need to investigate TCP_NIO.stop()

> MultiplexerTests don't work with TCP configuration
> --------------------------------------------------
>
>                 Key: JGRP-313
>                 URL: http://jira.jboss.com/jira/browse/JGRP-313
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> UDP works 100%, however, some of the tests fail with a TCP configuration

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 03:57:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 03:57:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <19090049.1158220657571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis reassigned JBAS-3641:
----------------------------------------

    Assignee: Dimitris Andreadis

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:11:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:11:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28749848.1158221498422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis reopened JBAS-3655:
--------------------------------------

             
I don't understand this "fix" at all. An interceptor of this type can either have a 
CTOR(MBeanInvoker)
or
CTOR()

The code simply tries the first one, then the second one. If the interceptor cannot be constructed at all, then this is something to be reported. There is no need to log WARN messages or legthy exceptions.

I changed this to:

         catch (Throwable t)
         {
            log.debug("Could not invoke CTOR(MBeanInvoker) for '"
                  + interceptorClass + "', trying default CTOR: " + t.getMessage()); 
            
            // Try the default ctor
            interceptor = (Interceptor) interceptorClass.newInstance();
         }

Anil, if you want to completely get rid of the debug message, add a CTOR(MBeanInvoker) to

org.jboss.jmx.connector.invoker.AuthorizationInterceptor
org.jboss.jmx.connector.invoker.AuthenticationInterceptor




> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:11:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:11:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24428068.1158221498627.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis updated JBAS-3655:
-------------------------------------

    Issue Type: Task  (was: Feature Request)

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:11:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:11:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Lower the log level
 for the ctr construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15528051.1158221498778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis updated JBAS-3655:
-------------------------------------

    Affects Version/s:     (was: JBossAS-4.0.4.GA)
                       JBossAS-4.0.5.CR1

> Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:39:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:39:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3655) Reduce logging for
 the construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8884185.1158223177300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis updated JBAS-3655:
-------------------------------------

              Summary: Reduce logging for the construction of interceptor in ModelMBeanInvoker  (was: Lower the log level for the ctr construction of interceptor in ModelMBeanInvoker)
        Fix Version/s: JBossAS-5.0.0.Beta
                       JBossAS-3.2.8.SP2
    Affects Version/s: JBossAS-3.2.8.SP1

> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 04:39:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 04:39:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3655) Reduce logging for
 the construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16546171.1158223177412.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3655?page=comments#action_12343303 ] 
            
Dimitris Andreadis commented on JBAS-3655:
------------------------------------------

I committed this to all branches


> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:05:37 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 05:05:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBWEB-16) scratchdir fails for
 multi-user installs
Message-ID: <30256772.1158224737038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBWEB-16?page=all ]

Luc Texier updated JBWEB-16:
----------------------------

    Comment: was deleted

> scratchdir fails for multi-user installs
> ----------------------------------------
>
>                 Key: JBWEB-16
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-16
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat Module
>    Affects Versions:  JBossWeb embedded - AS 4.0.1
>            Reporter: Norman Richards
>         Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8).   Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis.  Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. 
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:07:39 2006
From: jira-events at jboss.com (Luc Texier (JIRA))
Date: Thu, 14 Sep 2006 05:07:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-16) scratchdir fails
 for multi-user installs
Message-ID: <24746508.1158224859319.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-16?page=comments#action_12343306 ] 
            
Luc Texier commented on JBWEB-16:
---------------------------------

I removed my last comment which was erroneous

scratchdir is used only when compiling jsp pages

what you might consider is the following option instead
JAVA_OPTS="$JAVA_OPTS -Dcatalina.base=/tmp/catalina"

the server will then created the /work directory in there


> scratchdir fails for multi-user installs
> ----------------------------------------
>
>                 Key: JBWEB-16
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-16
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Tomcat Module
>    Affects Versions:  JBossWeb embedded - AS 4.0.1
>            Reporter: Norman Richards
>         Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8).   Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis.  Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property. 
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:13:46 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Thu, 14 Sep 2006 05:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <11620650.1158225226023.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12343307 ] 
            
Madhusudhan Konda commented on JBMESSAGING-407:
-----------------------------------------------

BTW, you need to add the following changes to conf/jbossjta-properties.xml:

<properties depends="arjuna" name="jta">
...
<property   name="com.arjuna.ats.jta.recovery.XAResourceRecoveryMessaging" value="org.jboss.jms.recovery.MessagingXAResourceRecovery;xaConnFac=XAConnectionFactory"/>
<property name="com.arjuna.ats.jta.xaRecoveryNode" value="*" />

..
</properties>

Note: the above properties MUST go under "jta" section (not the expected recoverymanager)

And

<properties depends="arjuna" name="recoverymanager">
..
 <property name="com.arjuna.ats.arjuna.recovery.recoveryExtension3" value="com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule"/>
...
</properties>



> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:13:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 05:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <10499285.1158225226264.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3641?page=comments#action_12343308 ] 
            
Dimitris Andreadis commented on JBAS-3641:
------------------------------------------

Thanks John.

I'll commit this to all brances, but can you please verify it works with the latest jboss-4.0.5.CR1 ?

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:13:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 05:13:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <6792224.1158225226489.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis updated JBAS-3641:
-------------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                   JBossAS-3.2.8.SP2

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:15:46 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 05:15:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <3224461.1158225346776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis updated JBAS-3641:
-------------------------------------

    Affects: [Compatibility/Configuration]

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 05:15:46 2006
From: jira-events at jboss.com (Madhusudhan Konda (JIRA))
Date: Thu, 14 Sep 2006 05:15:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <17557757.1158225346945.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=comments#action_12343309 ] 
            
Madhusudhan Konda commented on JBMESSAGING-407:
-----------------------------------------------

One of the things missing is - using the JMSProvderAdapter to fetch the jms provider as Adrian was using in his MQ recovery. I am working on this.

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 06:03:45 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 14 Sep 2006 06:03:45 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
In-Reply-To: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28648335.1158228225072.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3654?page=all ]

Adrian Brock updated JBAS-3654:
-------------------------------

    Issue Type: Feature Request  (was: Bug)

Changed to a feature request.

It has never been possible to depend upon an EAR
since an EAR is not a service.

Nor does the EAR lifecycle relate to its components in any direct way
beyond the initial construction of the subdeployments.

I'm pretty sure this is explained in the WIKI somewhere
along with the related FAQ about trying to depend upon JSR77 mbeans. :-)

> The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC1,  JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Dimitris Andreadis
>
> When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
> for example.  I have two ears example1. ear and example2.ear.
> I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
> So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml
>  <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
> This depends is working till jboss 4.0.1
> It fails in 4.0.3 SP1 , 4.0.4 GA
> 15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
> ment:war=crimeportal.war,id=-1360680885
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
> e: (javax.security.jacc.PolicyContextException: Operation not allowed)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
>         at org.jboss.web.WebModule.startModule(WebModule.java:68)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at org.jboss.system.ServiceController.start(ServiceController.java:446)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy21.start(Unknown Source)
>         at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy9.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
> tScanner.java:319)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
> canner.java:507)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
> doScan(AbstractDeploymentScanner.java:192)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
> bstractDeploymentScanner.java:265)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
>         at org.jboss.Main.boot(Main.java:187)
>         at org.jboss.Main$1.run(Main.java:438)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:201)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
> ossPolicyConfiguration.java:160)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
>         ... 94 more
> Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
> tion: linkConfiguration from state:inService
>         at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:196)
>         ... 96 more
> 15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
> ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
> 15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 06:57:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 06:57:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27877580.1158231462924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little closed JBESB-112.
-----------------------------

    Resolution: Done

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 14 06:59:44 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 06:59:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-11) Error redeploying
	dependent war
Message-ID: <14401878.1158231584539.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-11?page=all ]

Dimitris Andreadis updated JBAS-11:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

Scott points out that compex dependencies like this is really to be solved in JBoss5, so I'm rescheduling.

> Error redeploying dependent war
> -------------------------------
>
>                 Key: JBAS-11
>                 URL: http://jira.jboss.com/jira/browse/JBAS-11
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>    Affects Versions: JBossAS-4.0.0 Final
>            Reporter: bern
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-5.0.0.CR1
>
>
> This is a taken from the forum post from octopus see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=56015.
> I have a deployed webapp which depends on some mbean (having depends  clause in jboss-web.xml).
> When mbean is being redeployed it causes redeploying this webapp which finishes with NPE in WebModule.java
> This bug reproduced in both jboss 4.0.0 and 3.2.6
> Simple test case:
> Create sample service in /deploy, for example test-properties-service.xml
> Code:
> <server>
>     <mbean code="org.jboss.varia.property.SystemPropertiesService"
>         name="test:service=SystemProperties">
>         <!-- Set propertuies using the properties file style. -->
>         <attribute name="Properties">
>          </attribute>
>     </mbean>
> </server>
> 	
> Create sample war which depends on this service, for example
> Code:
> test.war
>            |
>             WEB-INF
>                           |
>                            web.xml
>                             jboss-web.xml
>            |
>              META-INF
> 	
> where web.xml
> Code:
> <web-app >
> </web-app>
> 	
> jboss-web.xml
> Code:
> <jboss-web>
>     <depends>test:service=SystemProperties</depends>
> </jboss-web>
> 	
> now both test-properties-service.xml and test.war placed in /deploy and deployed successfully.
> Now update test-properties-service.xml (edit-save, touch, etc)
> jboss will try to redeploy test.war with following result:
> Code:
> 13:22:33,483 DEBUG [MainDeployer] Undeploying file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-pr
> operties-service
> .xml
> 13:22:33,483 DEBUG [SARDeployer] undeploying document file:/C:/Cluster/jboss-3.2.6/server/all/deploy
> /test-properties
> -service.xml
> 13:22:33,499 DEBUG [SARDeployer] stopping mbean test:service=SystemProperties
> 13:22:33,499 DEBUG [ServiceController] stopping service: test:service=SystemProperties
> 13:22:33,514 DEBUG [ServiceController] stopping dependent services for: test:service=SystemPropertie
> s depende
> nt services are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: RUNNING
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:33,530 DEBUG [ServiceController] stopping service: jboss.web.deployment:war=test.war,id=-10807
> 43623
> 13:22:33,530 DEBUG [ServiceController] stopping dependent services for: jboss.web.deployment:war=tes
> t.war,id=-1080743623
> dependent services are: []
> 13:22:33,546 DEBUG [WebModule] Stopping jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,546 INFO  [TomcatDeployer] undeploy, ctxPath=/test, warUrl=file:/C:/Cluster/jboss-3.2.6/ser
> ver/all/tmp/deploy/tm
> p45130test.war/
> 13:22:33,577 DEBUG [Context] Stopping
> 13:22:33,577 DEBUG [Context] Stopping filters
> 13:22:33,577 DEBUG [Context]  Stopping filter 'CommonHeadersFilter'
> 13:22:33,592 DEBUG [Context] Processing standard container shutdown
> 13:22:33,608 DEBUG [Context] Sending application stop events
> 13:22:33,624 DEBUG [Context] resetContext jboss.web:j2eeType=WebModule,name=//localhost/test,J2EEApp
> lication=none,J2EESer
> ver=none org.jboss.mx.server.MBeanServerImpl at f99ff5
> 13:22:33,624 DEBUG [Context] Stopping complete
> 13:22:33,639 DEBUG [WebModule] Stopped jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,639 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.stop,sequenceNumber=225,timeStamp=10993981536
> 39,message=null,userD
> ata=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:33,655 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.stop,sequenceNumber=226,timeStamp=10993981536
> 55,message=null,userD
> ata=test:service=SystemProperties]
> 13:22:33,671 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.stop,sequenceNumber=114,timeStamp=10993981536
> 71,message=null,userD
> ata=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/deplo
> y/test-propertie
> s-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: Deployed
>   state: STARTED
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099397960936
>   lastModified: 1099397960874
>   mbeans:
>     test:service=SystemProperties state: Stopped
> ]
> 13:22:33,717 DEBUG [SARDeployer] destroying mbean test:service=SystemProperties
> 13:22:33,717 DEBUG [ServiceController] destroying service: test:service=SystemProperties
> 13:22:33,717 DEBUG [ServiceController] destroying dependent services for: test:service=SystemPropert
> ies depen
> dent services are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: STOPPED
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:33,749 DEBUG [ServiceController] destroying service: jboss.web.deployment:war=test.war,id=-108
> 0743623
> 13:22:33,749 DEBUG [ServiceController] destroying dependent services for: jboss.web.deployment:war=t
> est.war,id=-108074362
> 3 dependent services are: []
> 13:22:33,764 DEBUG [ServiceController] stopping service: jboss.web.deployment:war=test.war,id=-10807
> 43623
> 13:22:33,764 DEBUG [WebModule] Destroying jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,764 DEBUG [WebModule] Destroyed jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,764 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=227,timeStamp=10993981
> 53764,message=null,us
> erData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:33,780 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=
> 227,timeStamp=1099398
> 153764,message=null,userData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:33,811 DEBUG [ServiceController] stopping service: test:service=SystemProperties
> 13:22:33,811 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=228,timeStamp=10993981
> 53811,message=null,us
> erData=test:service=SystemProperties]
> 13:22:33,827 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.destroy,sequenceNumber=
> 228,timeStamp=1099398
> 153811,message=null,userData=test:service=SystemProperties]
> 13:22:33,827 DEBUG [SARDeployer] removing mbean test:service=SystemProperties
> 13:22:33,842 DEBUG [ServiceController] removing service: test:service=SystemProperties
> 13:22:33,842 DEBUG [ServiceController] removing test:service=SystemProperties from server
> 13:22:33,842 DEBUG [ServiceController] Context not removed, it is recording dependencies: ObjectName
> : test:se
> rvice=SystemProperties
>  state: DESTROYED
>  I Depend On:
>  Depends On Me:  jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:33,874 DEBUG [SARDeployer] Unregistering service UCL=jmx.loading:UCL=17210a5
> 13:22:33,874 DEBUG [UnifiedLoaderRepository3] UnifiedLoaderRepository removed(false) org.jboss.mx.lo
> ading.UnifiedClassLoa
> der3 at 17210a5{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/tmp45117test-properties-service
> .xml ,addedOrder
> =21}
> 13:22:33,889 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.destroy,sequenceNumber=115,timeStamp=10993981
> 53889,message=null,us
> erData=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/de
> ploy/test-proper
> ties-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: Deployed
>   state: STARTED
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099397960936
>   lastModified: 1099397960874
>   mbeans:
>     test:service=SystemProperties (state not available)
> ]
> 13:22:33,936 DEBUG [J2EEManagedObject] removeObject(), name: test:service=SystemProperties, encrypte
> d name: d
> ukascopy.system%3aservice%3dSystemProperties, search criteria: jboss.management.local:j2eeType=MBean
> ,*,name=test.sys
> tem%3aservice%3dSystemProperties
> 13:22:33,952 DEBUG [MBean] preDeregister(), parent: jboss.management.local:J2EEServer=Local,j2eeType
> =ServiceModule,name=d
> ukascopy-properties-service.xml
> 13:22:33,967 DEBUG [ServiceModuleFactory] Destroy MBean, name: test:service=SystemProperties
> 13:22:33,967 DEBUG [ServiceModule] destroy(), remove Service Module: test-properties-service.xml
> 13:22:33,967 DEBUG [J2EEManagedObject] removeObject(), name: test-properties-service.xml, encrypted 
> name: test-
> properties-service.xml, search criteria: jboss.management.local:j2eeType=ServiceModule,*,name=test-p
> roperties-servic
> e.xml
> 13:22:33,983 DEBUG [ServiceModule] preDeregister(), parent: jboss.management.local:j2eeType=J2EEServ
> er,name=Local
> 13:22:33,983 DEBUG [ServiceModuleFactory] Removed JSR-77 SAR: test-properties-service.xml
> 13:22:33,999 DEBUG [UnifiedClassLoader] Unregistering ucl=org.jboss.mx.loading.UnifiedClassLoader3 at 1
> 7210a5{ url=file:/C:/
> Cluster/jboss-3.2.6/server/all/tmp/deploy/tmp45117test-properties-service.xml ,addedOrder=21}
> 13:22:33,999 DEBUG [UnifiedLoaderRepository3] UnifiedLoaderRepository removed(true) org.jboss.mx.loa
> ding.UnifiedClassLoad
> er3 at 17210a5{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/tmp45117test-properties-service.
> xml ,addedOrder=
> 21}
> 13:22:34,014 DEBUG [DeploymentInfo] Cleaned Deployment: file:/C:/Cluster/jboss-3.2.6/server/all/tmp/
> deploy/tmp45117dukasc
> opy-properties-service.xml
> 13:22:34,014 DEBUG [MainDeployer] Undeployed file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-pro
> perties-service.
> xml
> 13:22:34,030 DEBUG [MainDeployer] Starting deployment of package: file:/C:/Cluster/jboss-3.2.6/serve
> r/all/deploy/dukascop
> y-properties-service.xml
> 13:22:34,030 DEBUG [MainDeployer] Starting deployment (init step) of package at: file:/C:/Cluster/jb
> oss-3.2.6/server/all/
> deploy/test-properties-service.xml
> 13:22:34,046 DEBUG [MainDeployer] Copying file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-proper
> ties-service.xml
>  -> C:\Cluster\jboss-3.2.6\server\all\tmp\deploy\tmp45131test-properties-service.xml
> 13:22:34,061 DEBUG [MainDeployer] using deployer org.jboss.deployment.SARDeployer at 15a0305
> 13:22:34,077 DEBUG [SARDeployer] about to copy 0 local directories
> 13:22:34,077 DEBUG [SARDeployer] looking for nested deployments in : file:/C:/Cluster/jboss-3.2.6/se
> rver/all/deploy/dukas
> copy-properties-service.xml
> 13:22:34,092 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.init,sequenceNumber=116,timeStamp=10993981540
> 92,message=null,userD
> ata=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/deplo
> y/test-propertie
> s-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: null
>   state: INIT_DEPLOYER
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 0
>   lastModified: 0
>   mbeans:
> ]
> 13:22:34,139 DEBUG [DeploymentInfo] createLoaderRepository from config: LoaderRepositoryConfig(repos
> itoryName: JMImplemen
> tation:service=LoaderRepository,name=Default, repositoryClassName: null, configParserClassName: null
> , repositoryConfig: n
> ull)
> 13:22:34,155 DEBUG [UnifiedClassLoader] New jmx UCL with url file:/C:/Cluster/jboss-3.2.6/server/all
> /tmp/deploy/tmp45131d
> ukascopy-properties-service.xml
> 13:22:34,155 DEBUG [UnifiedClassLoader] setRepository, r=org.jboss.mx.loading.UnifiedLoaderRepositor
> y3 at 1b8e059, ucl=org.j
> boss.mx.loading.UnifiedClassLoader3 at 37dde9{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/t
> mp45131test-prop
> erties-service.xml ,addedOrder=0}
> 13:22:34,171 DEBUG [UnifiedClassLoader] setRepository, r=org.jboss.mx.loading.UnifiedLoaderRepositor
> y3 at 1b8e059, ucl=org.j
> boss.mx.loading.UnifiedClassLoader3 at 37dde9{ url=file:/C:/Cluster/jboss-3.2.6/server/all/tmp/deploy/t
> mp45131test-prop
> erties-service.xml ,addedOrder=0}
> 13:22:34,186 DEBUG [UnifiedLoaderRepository3] Adding org.jboss.mx.loading.UnifiedClassLoader3 at 37dde9
> { url=file:/C:/Cluste
> r/jboss-3.2.6/server/all/tmp/deploy/tmp45131test-properties-service.xml ,addedOrder=0}
> 13:22:34,186 DEBUG [MainDeployer] found 0 subpackages of file:/C:/Cluster/jboss-3.2.6/server/all/dep
> loy/test-propert
> ies-service.xml
> 13:22:34,202 DEBUG [MainDeployer] Watching new file: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/
> test-properties-
> service.xml
> 13:22:34,202 DEBUG [MainDeployer] create step for deployment file:/C:/Cluster/jboss-3.2.6/server/all
> /deploy/test-pro
> perties-service.xml
> 13:22:34,217 DEBUG [SARDeployer] Deploying SAR, create step: url file:/C:/Cluster/jboss-3.2.6/server
> /all/deploy/test
> -properties-service.xml
> 13:22:34,217 DEBUG [SARDeployer] Registering service UCL=jmx.loading:UCL=37dde9
> 13:22:34,233 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:34,233 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=487 time=1099398154233 message=nul
> l objectName=jmx.load
> ing:UCL=37dde9 userData=null, handback:2147483647
> 13:22:34,264 DEBUG [ServiceCreator] About to create bean: test:service=SystemProperties with code: o
> rg.jboss.
> varia.property.SystemPropertiesService
> 13:22:34,280 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:34,280 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=488 time=1099398154280 message=nul
> l objectName=dukascop
> y.system:service=SystemProperties userData=null, handback:2147483647
> 13:22:34,296 DEBUG [ServiceCreator] Created bean: test:service=SystemProperties
> 13:22:34,296 DEBUG [ServiceConfigurator] Properties set to {test.mt.chart.chartserver.url=http://fre
> eserv.test.
> com/ru.test.server.auto.image/chart/, test.mt.datalayer.cache.url=rmi://192.168.100.174:1099/CacheSe
> rver} in du
> kascopy.system:service=SystemProperties
> 13:22:34,311 DEBUG [ServiceController] Creating service test:service=SystemProperties
> 13:22:34,311 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=229,timeStamp=109939815
> 4311,message=null,use
> rData=test:service=SystemProperties]
> 13:22:34,327 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=2
> 29,timeStamp=10993981
> 54311,message=null,userData=test:service=SystemProperties]
> 13:22:34,342 DEBUG [ServiceController] Creating dependent components for: test:service=SystemPropert
> ies depen
> dents are: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: DESTROYED
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:34,374 DEBUG [ServiceController] Creating service jboss.web.deployment:war=test.war,id=-108074
> 3623
> 13:22:34,374 DEBUG [WebModule] Creating jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:34,389 DEBUG [WebModule] Created jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:34,405 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=230,timeStamp=109939815
> 4405,message=null,use
> rData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:34,421 DEBUG [DefaultManagedObjectFactoryMap] Failed to find factory for event: javax.manageme
> nt.Notification[sourc
> e=jboss.system:service=ServiceController,type= org.jboss.system.ServiceMBean.create,sequenceNumber=2
> 30,timeStamp=10993981
> 54405,message=null,userData=jboss.web.deployment:war=test.war,id=-1080743623]
> 13:22:34,436 DEBUG [ServiceController] Creating dependent components for: jboss.web.deployment:war=t
> est.war,id=-108074362
> 3 dependents are: []
> 13:22:34,436 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.create,sequenceNumber=117,timeStamp=109939815
> 4436,message=null,use
> rData=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/dep
> loy/test-propert
> ies-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: null
>   state: CREATE_DEPLOYER
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099398154202
>   lastModified: 1099398154061
>   mbeans:
>     test:service=SystemProperties state: Created
> ]
> 13:22:34,483 DEBUG [MainDeployer] Done with create step of deploying test-properties-service.xml
> 13:22:34,499 DEBUG [MainDeployer] Begin deployment start file:/C:/Cluster/jboss-3.2.6/server/all/dep
> loy/test-propert
> ies-service.xml
> 13:22:34,499 DEBUG [SARDeployer] Deploying SAR, start step: url file:/C:/Cluster/jboss-3.2.6/server/
> all/deploy/test-
> properties-service.xml
> 13:22:34,514 DEBUG [ServiceController] starting service test:service=SystemProperties
> 13:22:34,514 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceController,type= org.jboss.system.ServiceMBean.start,sequenceNumber=231,timeStamp=1099398154
> 514,message=null,user
> Data=test:service=SystemProperties]
> 13:22:34,530 DEBUG [ServiceController] Starting dependent components for: test:service=SystemPropert
> ies depen
> dent components: [ObjectName: jboss.web.deployment:war=test.war,id=-1080743623
>  state: CREATED
>  I Depend On:  test:service=SystemProperties
>  Depends On Me: ]
> 13:22:34,546 DEBUG [ServiceController] starting service jboss.web.deployment:war=test.war,id=-108074
> 3623
> 13:22:34,546 DEBUG [WebModule] Starting jboss.web.deployment:war=test.war,id=-1080743623
> 13:22:34,561 ERROR [WebModule] Starting failed jboss.web.deployment:war=test.war,id=-1080743623
> java.lang.NullPointerException
>         at org.jboss.web.WebModule.startModule(WebModule.java:61)
>         at org.jboss.web.WebModule.startService(WebModule.java:40)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
>         at $Proxy18.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:414)
>         at org.jboss.system.ServiceController.start(ServiceController.java:436)
>         at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:251)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:829)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
>         at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy8.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:304)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:460)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeplo
> ymentScanner.java:201
> )
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploym
> entScanner.java:212)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeployme
> ntScanner.java:191)
> 13:22:34,717 WARN  [ServiceController] Problem starting service jboss.web.deployment:war=test.war,id
> =-1080743623
> RuntimeMBeanException: java.lang.NullPointerException
> Cause: java.lang.NullPointerException
>         at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.ja
> va:82)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:884)
>         at $Proxy18.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:414)
>         at org.jboss.system.ServiceController.start(ServiceController.java:436)
>         at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:251)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:829)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:641)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:604)
>         at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:62)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:54)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:82)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:197)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy8.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:304)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:460)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeplo
> ymentScanner.java:201
> )
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploym
> entScanner.java:212)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeployme
> ntScanner.java:191)
> Caused by: java.lang.NullPointerException
>         at org.jboss.web.WebModule.startModule(WebModule.java:61)
>         at org.jboss.web.WebModule.startService(WebModule.java:40)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:221)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         ... 40 more
> 13:22:34,921 DEBUG [LocalJBossServerDomain] handleNotification: javax.management.Notification[source
> =jboss.system:service
> =ServiceDeployer,type=org.jboss.deployment.SubDeployer.start,sequenceNumber=118,timeStamp=1099398154
> 921,message=null,user
> Data=org.jboss.deployment.DeploymentInfo at cb27219d { url=file:/C:/Cluster/jboss-3.2.6/server/all/depl
> oy/test-properti
> es-service.xml }
>   deployer: org.jboss.deployment.SARDeployer at 15a0305
>   status: Starting
>   state: START_DEPLOYER
>   watch: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/test-properties-service.xml
>   lastDeployed: 1099398154202
>   lastModified: 1099398154061
>   mbeans:
>     test:service=SystemProperties state: Started
> ]
> 13:22:34,967 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:34,967 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=489 time=1099398154967 message=nul
> l objectName=jboss.ma
> nagement.local:J2EEServer=Local,j2eeType=ServiceModule,name=test-properties-service.xml userData=nul
> l, handback:2147
> 483647
> 13:22:34,983 DEBUG [ServiceModule] postRegister(), parent: jboss.management.local:j2eeType=J2EEServe
> r,name=Local
> 13:22:34,999 DEBUG [ServiceModule] Created JSR-77 ServiceModule, name: test-properties-service.xml
> 13:22:34,999 DEBUG [ServiceModuleFactory] Created ServiceModule: jboss.management.local:J2EEServer=L
> ocal,j2eeType=Service
> Module,name=test-properties-service.xml
> 13:22:35,014 DEBUG [ModelMBeanInvoker] No persistence-manager descriptor found, null persistence wil
> l be used
> 13:22:35,014 DEBUG [SnmpAgentService] It's for me: javax.management.MBeanServerNotification: notific
> ationType=JMX.mbean.r
> egistered source=JMImplementation:type=MBeanServerDelegate seq-no=490 time=1099398155014 message=nul
> l objectName=jboss.ma
> nagement.local:J2EEApplication=null,J2EEServer=Local,ServiceModule=test-properties-service.xml,j2eeT
> ype=MBean,name=d
> ukascopy.system%3aservice%3dSystemProperties userData=null, handback:2147483647
> 13:22:35,030 DEBUG [MBean] postRegister(), parent: jboss.management.local:J2EEServer=Local,j2eeType=
> ServiceModule,name=du
> kascopy-properties-service.xml
> 13:22:35,046 DEBUG [ServiceModuleFactory] Create MBean, name: test:service=SystemProperties, SAR Mod
> ule: jbos
> s.management.local:J2EEServer=Local,j2eeType=ServiceModule,name=test-properties-service.xml
> 13:22:35,046 DEBUG [MainDeployer] End deployment start on package: test-properties-service.xml
> 13:22:35,046 DEBUG [MainDeployer] Deployed package: file:/C:/Cluster/jboss-3.2.6/server/all/deploy/t
> est-properties-s
> ervice.xml

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 07:03:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 07:03:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1490) EJB component
 environment (ENC) is not read only
Message-ID: <26812679.1158231818602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1490?page=all ]

Dimitris Andreadis updated JBAS-1490:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> EJB component environment (ENC) is not read only
> ------------------------------------------------
>
>                 Key: JBAS-1490
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1490
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-3.2.6 Final
>         Environment: Windows XP
>            Reporter: Tim Fox
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The component JNDI environment for a Stateless session bean does not appear to be read-only.
> I have a SLSB running in 3.2.6.
> It attempts to modify it's ENC (java:comp/env environment) and succeeds. I.e. the following succeeds:
> InitialContext ic = new InitialContext();
> Context envCtx = (Context)new InitialContext().lookup("java:comp/env");
> envCtx.bind("foo", "bar");
> log.debug("Worked!!");
> Also bind stuff into the context works.
> I haven't tried with other types of EJB.
> According to the EJB 2.0 spec (Sec. 20.2.4) an enterprise beans's environment should be read-only.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 07:03:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 07:03:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3614) failing
 org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
In-Reply-To: <5797013.1157137545169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2291995.1158231818746.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3614?page=all ]

Dimitris Andreadis reassigned JBAS-3614:
----------------------------------------

    Assignee: Dimitris Andreadis  (was: Scott M Stark)

> failing org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3614
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3614
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> testRMMResourceImplementsMBean Failure
> testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> junit.framework.AssertionFailedError: testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> 	at org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase.testRMMResourceImplementsMBean(ModelMBeanTestCase.java:150)
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 07:19:37 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 07:19:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-137) Race condition in
	GPListener
Message-ID: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>

Race condition in GPListener
----------------------------

                 Key: JBESB-137
                 URL: http://jira.jboss.com/jira/browse/JBESB-137
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Esteban Schifman
             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 14 07:19:37 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 07:19:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10259769.1158232777684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little closed JBESB-137.
-----------------------------

    Resolution: Done

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 14 08:27:37 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Thu, 14 Sep 2006 08:27:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10727563.1158236857260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=all ]

Roland R?z reopened EJBTHREE-679:
---------------------------------

             
http://jira.jboss.com/jira/browse/JBINSTALL-42


I think that the Properties Service is not sufficient to provide a different naming convention. What I thought about was a way  to plug in a different default naming convention.

The interface could look like this:

public interface DefaultJndiNameProvider {
	String getDefaultRemoteJndiName(Container container);
	String getDefaultLocalJndiName(Container container);
}

Currently the org.jboss.ejb3.ProxyFactoryHelper uses the  [<earname>/]<ejbname>/[remote|local] naming convention. We use a different naming convention to support multiple jboss instances which can use each other. With a default jndi name provider we could get rid of the "pain" from configuring the jndi name for each bean.

The implementation of the DefaultJndiNameProvider could be configured using a System Property.


> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 08:55:34 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 08:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3600) failure (jrockit)
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <9851480.1157131424103.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1114078.1158238534998.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3600?page=all ]

Dimitris Andreadis closed JBAS-3600.
------------------------------------

       Resolution: Done
         Assignee: Dimitris Andreadis
    Fix Version/s: JBossAS-5.0.0.Beta

Fixed the order of tests

> failure (jrockit) org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3600
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3600
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> test402Compatibility fails. I don't understand how the same test passes with jdk1.4. Is the serialVersionGUID computed differently?
> Failure Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent, javax.management.loading.MLet, javax.resource.ResourceException, javax.resource.spi.ConnectionEvent, javax.resource.spi.InvalidPropertyException, javax.resource.spi.work.WorkEvent, javax.security.jacc.EJBMethodPermission, javax.security.jacc.EJBRoleRefPermission, javax.security.jacc.WebResourcePermission, javax.security.jacc.WebRoleRefPermission, javax.security.jacc.WebUserDataPermission, javax.xml.registry.JAXRException, javax.xml.registry.RegistryException, javax.xml.rpc.JAXRPCException, javax.xml.rpc.ServiceException, javax.xml.rpc.soap.SOAPFaultException, javax.xml.soap.SOAPException
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.enterprise.deploy.spi.status.ProgressEvent,
> javax.management.loading.MLet,
> javax.resource.ResourceException,
> javax.resource.spi.ConnectionEvent,
> javax.resource.spi.InvalidPropertyException,
> javax.resource.spi.work.WorkEvent,
> javax.security.jacc.EJBMethodPermission,
> javax.security.jacc.EJBRoleRefPermission,
> javax.security.jacc.WebResourcePermission,
> javax.security.jacc.WebRoleRefPermission,
> javax.security.jacc.WebUserDataPermission,
> javax.xml.registry.JAXRException,
> javax.xml.registry.RegistryException,
> javax.xml.rpc.JAXRPCException,
> javax.xml.rpc.ServiceException,
> javax.xml.rpc.soap.SOAPFaultException,
> javax.xml.soap.SOAPException
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Thu Sep 14 09:05:41 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 14 Sep 2006 09:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7846137.1158239141333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Thomas Diesler updated JBAS-3626:
---------------------------------

    Summary: Upgrade jbossws to 1.1.0.GA  (was: Upgrade jbossws to 1.0.4.GA)

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.GA
>
>
> Upgrade to jbossws-1.0.4.GA, when it becomes available

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:05:41 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 14 Sep 2006 09:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30555812.1158239141497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Thomas Diesler updated JBAS-3626:
---------------------------------

    Description:     (was: Upgrade to jbossws-1.0.4.GA, when it becomes available)

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 14 09:05:41 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 14 Sep 2006 09:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18908320.1158239141667.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3626?page=comments#action_12343317 ] 
            
Thomas Diesler commented on JBAS-3626:
--------------------------------------

Release date is 31-Oct-2006

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 14 09:27:38 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 14 Sep 2006 09:27:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3655) Reduce logging for
 the construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7494852.1158240458133.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3655?page=comments#action_12343318 ] 
            
Anil Saldhana commented on JBAS-3655:
-------------------------------------

As long as there is no lengthy exception, I am fine. I do not think there is a necessity for every interceptor to have an injection of MBeanInvoker.

Please close the issue. I am not adding the ctrs to AuthxxxInterceptors.

> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:31:35 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Thu, 14 Sep 2006 09:31:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-136) Define a set of
 EPRs for Email, Ftp and Database.
In-Reply-To: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12863353.1158240695984.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-136?page=comments#action_12343319 ] 
            
Arvinder Singh commented on JBESB-136:
--------------------------------------

Added basic email-epr/email xsd skeleton under workspace/rearchitecture. More progress to follow

> Define a set of EPRs for Email, Ftp and Database.
> -------------------------------------------------
>
>                 Key: JBESB-136
>                 URL: http://jira.jboss.com/jira/browse/JBESB-136
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Arvinder Singh
>         Assigned To: Arvinder Singh
>             Fix For: 4.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:45:49 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 09:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16040187.1158241549937.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Dimitris Andreadis updated JBAS-3626:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
                   JBossAS-4.0.6.CR1

The 4.0.5.GA release will come earlier, so rescheduling the upgrade for 4.0.6.CR1.

If jbossws-1.1.0 could be used as a drop-in replacement for 1.0.3 that would by handy.

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:45:50 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 09:45:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.1.0.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26559099.1158241550135.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Dimitris Andreadis updated JBAS-3626:
-------------------------------------

    Affects Version/s:     (was: JBossAS-4.0.5.CR1)

> Upgrade jbossws to 1.1.0.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:49:52 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 09:49:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3655) Reduce logging for the
 construction of interceptor in ModelMBeanInvoker
In-Reply-To: <3473824.1158180154219.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30935255.1158241792457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3655?page=all ]

Dimitris Andreadis closed JBAS-3655.
------------------------------------

      Assignee: Dimitris Andreadis  (was: Anil Saldhana)
    Resolution: Done

The lengthy exception is gone.

> Reduce logging for the construction of interceptor in ModelMBeanInvoker
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3655
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3655
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security, JMX
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>
> 2006-09-12 11:59:11,238 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthenticationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthenticationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654) 
> .....
> 2006-09-12 11:59:11,491 DEBUG [org.jboss.mx.modelmbean.ModelMBeanInvoker] Failed to invoke ctor(MBeanInvoker) for: class org.jboss.jmx.connector.invoker.AuthorizationInterceptor
> java.lang.NoSuchMethodException: org.jboss.jmx.connector.invoker.AuthorizationInterceptor.<init>(org.jboss.mx.server.MBeanInvoker)
> 	at java.lang.Class.getConstructor0(Class.java:2678)
> 	at java.lang.Class.getConstructor(Class.java:1629)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.getInterceptors(ModelMBeanInvoker.java:739)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.configureInterceptorStack(ModelMBeanInvoker.java:678)
> 	at org.jboss.mx.modelmbean.XMBean.configureInterceptorStack(XMBean.java:400)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.init(ModelMBeanInvoker.java:504)
> 	at org.jboss.mx.modelmbean.ModelMBeanInvoker.invokePreRegister(ModelMBeanInvoker.java:486)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.preRegister(AbstractMBeanInvoker.java:654)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.invokePreRegister(BasicMBeanRegistry.java:697)
> 	at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:211) 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 09:54:47 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 09:54:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-257) Test extender test
 in a scoped environment
Message-ID: <1921954.1158242087259.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-257?page=comments#action_12343322 ] 
            
Kabir Khan commented on JBAOP-257:
----------------------------------

Construtors done

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:29:48 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Thu, 14 Sep 2006 10:29:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1004) Jboss Portal to
 support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22320242.1158244188149.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=all ]

Sverker Abrahamsson updated JBPORTAL-1004:
------------------------------------------

    Attachment: jboss-portal-2.4-2.patch

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4-2.patch, jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:33:47 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Thu, 14 Sep 2006 10:33:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30461399.1158244427740.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343323 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

I have uploaded a new patch which binds virtual hosts to the portal instead of context.


> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4-2.patch, jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:53:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:53:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-119) Parameter loading
 doesn't check for XML validity
In-Reply-To: <7780536.1154950212823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21450027.1158245627544.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-119?page=all ]

Mark Little reassigned JBESB-119:
---------------------------------

    Assignee: Esteban Schifman  (was: Mark Little)

> Parameter loading doesn't check for XML validity
> ------------------------------------------------
>
>                 Key: JBESB-119
>                 URL: http://jira.jboss.com/jira/browse/JBESB-119
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>            Priority: Critical
>             Fix For: 4.0
>
>
> The current ParamRepository approach has a File implementation. It all appears to work on Strings (with the comments indicating how the strings should be formatted for structured attributes). However, some user classes assume the String is XML. Parameters should be provided to application classes through name/value pairs. How those pairs are loaded into the system (XML, strings, file, etc.) should be hidden.
> We also need an ESB schema.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:55:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:55:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-122) Schema needed
In-Reply-To: <17213696.1154955972421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13232847.1158245747498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-122?page=all ]

Mark Little reassigned JBESB-122:
---------------------------------

    Assignee: Esteban Schifman  (was: Mark Little)

> Schema needed
> -------------
>
>                 Key: JBESB-122
>                 URL: http://jira.jboss.com/jira/browse/JBESB-122
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>            Priority: Critical
>             Fix For: 4.0
>
>
> XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-120) ObjectStore
 configured differently from other components
In-Reply-To: <8533363.1154951052094.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32239071.1158245867604.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-120?page=all ]

Mark Little reassigned JBESB-120:
---------------------------------

    Assignee: Daniel Brum  (was: Kurt Stam)

> ObjectStore configured differently from other components
> --------------------------------------------------------
>
>                 Key: JBESB-120
>                 URL: http://jira.jboss.com/jira/browse/JBESB-120
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0
>
>
> Why does the object store configuration work differently from other components? Specifically, it doesn't use the ParamsRepository approach.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-48) I18N/L10N compliance
Message-ID: <15136899.1158245867781.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-48?page=all ]

Mark Little updated JBESB-48:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> I18N/L10N compliance
> --------------------
>
>                 Key: JBESB-48
>                 URL: http://jira.jboss.com/jira/browse/JBESB-48
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Optional
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:59:48 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:59:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-70) Create separate
	Nagios plugin
Message-ID: <9200412.1158245988069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-70?page=all ]

Mark Little updated JBESB-70:
-----------------------------

    Fix Version/s:     (was: 4.0)
                   4.1

> Create separate Nagios plugin
> -----------------------------
>
>                 Key: JBESB-70
>                 URL: http://jira.jboss.com/jira/browse/JBESB-70
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Johan Kumps
>             Fix For: 4.1
>
>
> - common\src\org\jboss\soa\esb\util\NagiosStandaloneHeartbeat.java
> 1) Refactor into a nagios specific plugin package? 

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 10:59:48 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 10:59:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-117) Variable names should
 be more readable
In-Reply-To: <19656339.1154939172165.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9558634.1158245988215.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-117?page=all ]

Mark Little closed JBESB-117.
-----------------------------

    Resolution: Done

This should be fixed as part of the move to a coding convention.

> Variable names should be more readable
> --------------------------------------
>
>                 Key: JBESB-117
>                 URL: http://jira.jboss.com/jira/browse/JBESB-117
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> Some variables in the code are shortened and difficult to read.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:01:48 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:01:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18408709.1158246108490.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little updated JBESB-118:
------------------------------

    Fix Version/s:     (was: 4.0)
                   4.1

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-44) Transaction bridging
Message-ID: <16451736.1158249467568.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-44?page=all ]

Mark Little updated JBTM-44:
----------------------------

    Fix Version/s:     (was: 4.4)
                   4.6

> Transaction bridging
> --------------------
>
>                 Key: JBTM-44
>                 URL: http://jira.jboss.com/jira/browse/JBTM-44
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation, WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.6
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-50) Open source WS-Context
 implementation
Message-ID: <30076197.1158249467704.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-50?page=all ]

Mark Little updated JBTM-50:
----------------------------

    Fix Version/s:     (was: 4.4)
                   4.6

> Open source WS-Context implementation
> -------------------------------------
>
>                 Key: JBTM-50
>                 URL: http://jira.jboss.com/jira/browse/JBTM-50
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.6
>
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 11:57:47 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 11:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-123) Integrate with AS 5.0
Message-ID: <31369972.1158249467860.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate with AS 5.0
---------------------

                 Key: JBTM-123
                 URL: http://jira.jboss.com/jira/browse/JBTM-123
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Jonathan Halliday
             Fix For: 4.4




-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:02:39 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 12:02:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-20) Ensure ATS logging
 capabilities are compatible with JBoss
Message-ID: <6757195.1158249759200.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-20?page=all ]

Mark Little reassigned JBTM-20:
-------------------------------

    Assignee: Jonathan Halliday  (was: Kevin Conner)

> Ensure ATS logging capabilities are compatible with JBoss
> ---------------------------------------------------------
>
>                 Key: JBTM-20
>                 URL: http://jira.jboss.com/jira/browse/JBTM-20
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>            Priority: Minor
>             Fix For: 4.4
>
>
> ATS has its own way of logging errors, warnings, debugging etc. Although it follows JDK 1.4 logging specification (and can use log4j as an implementation), we need to ensure it is compatible with the standard way of logging in the result of JBoss.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:02:39 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 12:02:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4304387.1158249759362.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-98?page=all ]

Mark Little reassigned JBTM-98:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:02:39 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 14 Sep 2006 12:02:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-92) Print error message
 when prepare fails in XAResource
Message-ID: <31701589.1158249759521.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-92?page=all ]

Mark Little reassigned JBTM-92:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> 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: Jonathan Halliday
>            Priority: Minor
>             Fix For: 4.4
>
>
> 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

        


From jira-events at jboss.com  Thu Sep 14 12:30:35 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-257) Test extender test in
 a scoped environment
Message-ID: <18885220.1158251435507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-257?page=all ]

Kabir Khan closed JBAOP-257.
----------------------------

    Resolution: Done

> Test extender test in a scoped environment
> ------------------------------------------
>
>                 Key: JBAOP-257
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-257
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> Repackage a new test based on the testsuite test org.jboss.test.aop.test.ExtenderTestCase where the base classes are in a parent/non-scoped classloader and the sub-classes are in a scoped classloader.
> There should be at least two copies of the sub class packages, being intercepted by different things.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:40:36 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:40:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-285) overloaded method
 super calls do not get intercepted with generated advisors
Message-ID: <19742940.1158252037003.JavaMail.jira@cloud.prod.atl2.jboss.com>

overloaded method super calls do not get intercepted with generated advisors
----------------------------------------------------------------------------

                 Key: JBAOP-285
                 URL: http://jira.jboss.com/jira/browse/JBAOP-285
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.0.0.alpha


class Base{
   void superCall(){}
}

class Sub extends Base{
   void superCall(){super.superCall();}
}

<bind pointcut="execution(* $instanceof{Base}->superCall())">
   <interceptor class="X"/>
</bind>

Sub sub = new Sub();
sub.superCall();

We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. 

I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:48:39 2006
From: jira-events at jboss.com (Jason Lenhart (JIRA))
Date: Thu, 14 Sep 2006 12:48:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-129) Wrong jar referred
 to in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11038848.1158252519303.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Jason Lenhart updated JBESB-129:
--------------------------------

    Complexity: Low

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:57:47 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <1077004.1158253067602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment: jboss-aop.jar

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 12:57:47 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 14 Sep 2006 12:57:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <29689996.1158253067797.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment:     (was: jboss-aop.jar)

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:04:41 2006
From: jira-events at jboss.com (Marcos Tengelmann (JIRA))
Date: Thu, 14 Sep 2006 13:04:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-495) Allows for
 automatic meta data
 gathering during rule/rule package saves to repository
Message-ID: <32823093.1158253481712.JavaMail.jira@cloud.prod.atl2.jboss.com>

Allows for automatic meta data gathering during rule/rule package saves to repository
-------------------------------------------------------------------------------------

                 Key: JBRULES-495
                 URL: http://jira.jboss.com/jira/browse/JBRULES-495
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: drools-brms
            Reporter: Marcos Tengelmann
         Assigned To: Mark Proctor
            Priority: Optional


In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.

The whole idea here is to keep the concept of Category only for business purposes.

Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions

With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:17:36 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 14 Sep 2006 13:17:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1036) Portlet
 container uses a
 log4j logger that use the portlet class name as category which leads to
 create a logger and prevent that portlet to uses its own logger factory
In-Reply-To: <18721496.1158185551286.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9060183.1158254256682.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1036?page=all ]

Julien Viet resolved JBPORTAL-1036.
-----------------------------------

    Resolution: Done

> Portlet container uses a log4j logger that use the portlet class name as category which leads to create a logger and prevent that portlet to uses its own logger factory
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1036
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1036
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.2.1 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.2.2 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:37:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:37:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3126) Add tests for
 org.jboss.varia.scheduler facility
Message-ID: <13944163.1158255457188.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3126?page=all ]

Dimitris Andreadis updated JBAS-3126:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
                   JBossAS-4.0.6.CR1

> Add tests for org.jboss.varia.scheduler facility
> ------------------------------------------------
>
>                 Key: JBAS-3126
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3126
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We have zero tests for the scheduler stuff, so add this task as a reminder.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:43:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:43:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3658) Remote classloading
 service - Redesign
Message-ID: <2583525.1158255817852.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remote classloading service - Redesign
--------------------------------------

                 Key: JBAS-3658
                 URL: http://jira.jboss.com/jira/browse/JBAS-3658
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Remoting
            Reporter: Dimitris Andreadis
         Assigned To: Tom  Elrod
             Fix For: JBossAS-4.0.6.CR1


We need to redesign the remote classloading service such that there is more control at the deployment layer on what is exposed.

I will create a forum thread where this can be discussed in more detail.

Requirement 1:
Provide sensible defaults, which probably means no remote classloading by default

Requirement 2:
Individual deployments can choose whether remote classloading is enabled and what is available remotely

Requirement 3:
Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or AOP remoting proxies

Requirement 4:
Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable

Requirement 5:
Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that triggers the use of invokers to do remote classloading.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:45:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:45:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2075) Remote classloading
 service - Redesign
Message-ID: <13862711.1158255939387.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2075?page=all ]

Dimitris Andreadis closed JBAS-2075.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Duplicate Issue

Re-opened this subtask as a feature request for the next release.

> Remote classloading service - Redesign
> --------------------------------------
>
>                 Key: JBAS-2075
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2075
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions:  JBossAS-4.0.3RC1
>            Reporter: Adrian Brock
>
> We need to redesign the remote classloading service such that there is more control at the deployment layer
> on what is exposed.
> I will create a forum thread where this can be discussed in more detail.
> Requirement 1:
> Provide sensible defaults, which probably means no remote classloading by default
> Requirement 2:
> Individual deployments can choose whether remote classloading is enabled and what is available remotely
> Requirement 3:
> Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or
> AOP remoting proxies
> Requirement 4:
> Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable
> Requirement 5:
> Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that
> triggers the use of invokers to do remote classloading.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:47:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:47:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2057) Need an EJB3 mbean
	JSR-77 mapping
Message-ID: <12833881.1158256057598.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2057?page=all ]

Dimitris Andreadis updated JBAS-2057:
-------------------------------------

     Issue Type: Feature Request  (was: Task)
    Component/s: EJB3
                 Management services
                     (was: EJB2)

> Need an EJB3 mbean JSR-77 mapping
> ---------------------------------
>
>                 Key: JBAS-2057
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2057
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just work.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:47:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:47:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2057) Need an EJB3 mbean
 JSR-77 mapping
Message-ID: <3351149.1158256057795.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2057?page=comments#action_12343332 ] 
            
Dimitris Andreadis commented on JBAS-2057:
------------------------------------------

I don't think we have free cycles for this now.

> Need an EJB3 mbean JSR-77 mapping
> ---------------------------------
>
>                 Key: JBAS-2057
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2057
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just work.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:59:38 2006
From: jira-events at jboss.com (Fabrice Daugan (JIRA))
Date: Thu, 14 Sep 2006 13:59:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-346) This project
 cannot be deployed to a server.
In-Reply-To: <24697603.1154610791446.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6361530.1158256778830.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-346?page=comments#action_12343333 ] 
            
Fabrice Daugan commented on JBIDE-346:
--------------------------------------

Exactly the same for :
- Windows XP Pro SP 2
- Java 1.5.0_07
- JBossAS 4.0.4.GA (build: CVSTag=JBoss_4_0_4_GA date=200605151000)
- JBoss IDE 2.0.0 beta 1
- J2EE 1.3 and 1.4

> This project cannot be deployed to a server.
> --------------------------------------------
>
>                 Key: JBIDE-346
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-346
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossIDE Core
>    Affects Versions: 2.0.0.Alpha1a
>         Environment: - Windoze XP Pro SP 2
> - Java 1.5.0_07
> - JBossAS 4.0.4 GA patch 1
> - JBoss IDE 2.0.0 alpha 1a
>            Reporter: Michael Vilot
>         Assigned To: Marshall Culpepper
>
> After creating a J2EE 1.4 project and running XDoclet to generate the needed descriptors, unable to deploy.
> For Project -> Properties -> Server, dialog box says "This project cannot be deployed to a server."
> For Run -> Debug (?!?!) -> no JBoss server configuration appears.
> However, for New -> Server, a JBoss 4 server option appears, can be configured, and can be run/stopped from Eclipse. Unfortunately, the J2EE part of JBoss IDE does not recognize it at all.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 13:59:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 13:59:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2477) Exception in
 web-console j2ee domain after undeploy of application
Message-ID: <32489885.1158256779433.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2477?page=all ]

Dimitris Andreadis updated JBAS-2477:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Exception in web-console j2ee domain after undeploy of application
> ------------------------------------------------------------------
>
>                 Key: JBAS-2477
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2477
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Both Linux and Windows
>            Reporter: Lennart Petersson
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Had listed all apps in web-console j2ee domains. Then undeployed one app. Then list again in web-console ---> exception below.
> 10:31:54,896 INFO  [TomcatDeployer] undeploy, ctxPath=/crimeportal, warUrl=.../tmp/deploy/tmp65013crimeportal.war/
> 10:31:54,914 INFO  [EJBDeployer] Undeploying: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/CrimePortalBeans.jar
> 10:31:55,162 INFO  [ProxyFactory] Unbind EJB Home 'SicilianLaundry' from jndi 'SicilianLaundry'
> 10:31:55,172 INFO  [EjbModule] Undeployed SicilianLaundry
> 10:31:55,173 INFO  [ProxyFactory] Unbind EJB Home 'ShanghaiLaundry' from jndi 'ShanghaiLaundry'
> 10:31:55,173 INFO  [EjbModule] Undeployed ShanghaiLaundry
> 10:31:55,190 INFO  [EARDeployer] Undeploying J2EE application, destroy step: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/
> 10:32:01,401 INFO  [STDOUT] javax.management.InstanceNotFoundException: jboss.management.local:J2EEApplication=CrimePortal.ear,J2EEServer=Local,j2eeType=EJBModule,name=CrimePortalBeans.jar is not registered.
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:651)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDeployedObjects(JSR77Lister.java:167)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServer(JSR77Lister.java:194)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServers(JSR77Lister.java:218)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomain(JSR77Lister.java:233)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomains(JSR77Lister.java:256)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.getTreeForResource(JSR77Lister.java:282)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.helpers.AbstractPluginWrapper.getSubTreeForResource(AbstractPluginWrapper.java:201)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreesForResource(PluginManager.java:392)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreeForProfile(PluginManager.java:192)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:32:01,411 INFO  [STDOUT]     at java.lang.reflect.Method.invoke(Method.java:324)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.processRequest(InvokerServlet.java:90)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.doPost(InvokerServlet.java:133)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 10:32:01,430 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:534)
> 1

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 14:09:37 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 14 Sep 2006 14:09:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3346)
 org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase
 causes 1.5 BEA JVM to core dump
Message-ID: <26782177.1158257377470.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3346?page=comments#action_12343334 ] 
            
Dimitris Andreadis commented on JBAS-3346:
------------------------------------------

We have been running the jboss testsuite on Branch_4_0 using bea jdk 1.5 for some time without any JVM core dumps.

http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-testsuite-1.5

Java Version 1.5.0_06 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.5.0_06-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-34.0.2.ELsmp 
OS Arch i386 


> org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase causes 1.5 BEA JVM to core dump
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3346
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: RHEL 4, x86_64 processor, BEA 1,5 JDK
>            Reporter: Len DiMaggio
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> With this JDK:
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> BEA JRockit(R) (build dra-45238-20050523-2021-linux-x86_64, R25.2.0-28)
> And this test from the JBoss 4.0.4/GA test suite (download from jboss.com) - the test causes a code dump when it executes line 62.
>      1	/*
>      2	* JBoss, Home of Professional Open Source
>      3	* Copyright 2005, JBoss Inc., and individual contributors as indicated
>      4	* by the @authors tag. See the copyright.txt in the distribution for a
>      5	* full listing of individual contributors.
>      6	*
>      7	* This is free software; you can redistribute it and/or modify it
>      8	* under the terms of the GNU Lesser General Public License as
>      9	* published by the Free Software Foundation; either version 2.1 of
>     10	* the License, or (at your option) any later version.
>     11	*
>     12	* This software is distributed in the hope that it will be useful,
>     13	* but WITHOUT ANY WARRANTY; without even the implied warranty of
>     14	* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>     15	* Lesser General Public License for more details.
>     16	*
>     17	* You should have received a copy of the GNU Lesser General Public
>     18	* License along with this software; if not, write to the Free
>     19	* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>     20	* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>     21	*/
>     22	package org.jboss.test.cmp2.batchcascadedelete.test;
>     23	
>     24	import org.jboss.test.JBossTestCase;
>     25	import org.jboss.test.cmp2.batchcascadedelete.ejb.Child;
>     26	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildHome;
>     27	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildUtil;
>     28	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildHome;
>     29	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildUtil;
>     30	import org.jboss.test.cmp2.batchcascadedelete.ejb.Parent;
>     31	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentHome;
>     32	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentUtil;
>     33	import junit.framework.Test;
>     34	
>     35	/**
>     36	 * @author <a href="mailto:alex at jboss.org">Alexey Loubyansky</a>
>     37	 * @version <tt>$Revision: 1.1.2.2 $</tt>
>     38	 */
>     39	public class BatchCascadeDeleteUnitTestCase
>     40	   extends JBossTestCase
>     41	{
>     42	   /**
>     43	    * Constructor for the JBossTestCase object
>     44	    *
>     45	    * @param name Test case name
>     46	    */
>     47	   public BatchCascadeDeleteUnitTestCase(String name)
>     48	   {
>     49	      super(name);
>     50	   }
>     51	
>     52	   public static Test suite() throws Exception
>     53	   {
>     54	      return JBossTestCase.getDeploySetup(BatchCascadeDeleteUnitTestCase.class, "cmp2-batchcascadedelete.jar");
>     55	   }
>     56	
>     57	   public void testCase4540() throws Exception
>     58	   {
>     59	      ParentHome parentHome = ParentUtil.getHome();
>     60	      Parent parent = parentHome.create("parent");
>     61	
>     62	      ChildHome childHome = ChildUtil.getHome();
>     63	      Child child = childHome.create( parent, "child");
>     64	
>     65	      GrandchildHome grandchildHome = GrandchildUtil.getHome();
>     66	
>     67	      // If you comment out the next line, then the call to child.remove() works fine.
>     68	      grandchildHome.create(child.getId(), "grandchild");
>     69	
>     70	      this is the test for non-null foreign key
>     71	      child.remove();
>     72	   }
>     73	}
> Here's the dump file:
> Linux x86_64-4as.lab.boston.redhat.com 2.6.9-39.ELsmp #1 SMP Thu Jun 1 18:01:55 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> ===== BEGIN DUMP =============================================================
> JRockit dump produced after 0 days, 00:29:38 on Wed Jun 21 13:56:36 2006
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Error Message: Illegal memory access. [54]
> Signal info  : si_signo=12, si_code=-6
> Version      : BEA JRockit(R) R25.2.0-28 dra-45238-20050523-2021-linux-x86_64
> GC           : System optimized over throughput (initial strategy singleparpar)
>              : GC strategy for GC 4 was genparpar
>              : GC strategy for GC 5 was singleparpar
>              : GC strategy for GC 6 was genparpar
>              : GC strategy for GC 7 was singleparpar
>              : GC strategy for GC 8 was genparpar
>              : mmHeap->data = 0x20000000, mmHeap->top = 0x28000000
>              : mmStartCompaction = 0x21800000, mmEndCompaction = 0x22000000
> CPU          : Intel Pentium 4 SSE SSE2 NetBurst EM64T
> Number CPUs  : 2
> Tot Phys Mem : 4120244224
> OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 4 Beta)
> Linux version 2.6.9-39.ELsmp (bhcompile at hs20-bc1-6.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Thu Jun 1 18:01:55 EDT 2006
> State        : JVM is running (Main thread has finished)
> Command Line : -Djrockit.launcher.type=jrockit.shipment -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/lib/endorsed org.jboss.Main -c all
> Environment  : JAVA_HOME=(null), java.home=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre, java.class.path=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar, java.library.path=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/../lib/amd64
> C Heap       : Good; no memory allocations have failed
> Registers (from context struct at 0x40e899f8/0x40e89a70):
> RAX = ffffffff00000010  RBX = 00000000f7bc5de8
> RCX = 00000000f7bc5df8  RDX = 00000000ffcb1bf3
> R8  = 000000000002feeb  R9  = 000000009090feeb
> R10 = 0000002a9b7aeed0  R11 = 0000002a9577893c
> R12 = 0000000040e89e58  R13 = 0000000000000001
> R14 = 0000000000000001  R15 = 0000002a9b7aed08
> RSI = 0000000020c8bb78  RDI = 00000000220b1108
> RSP = 0000000040e89eb0  RIP = 00000001009ccec8
> RBP = 00000000220b1108  RFL = 00000206
> CS = 0000 GS = 0000 FS = 0000
> Stack:
> 0000000040e89eb0: 0000000021ff0238 00000001009ccbb5 00000000220d6b28 0000000020c81130 0000000022078920 0000000021ff0238 
> 0000000040e89ee0: 0000000100000a22 0000000003c3d730 00000000220d6b40 0000000020c8bb48 0000000022078920 0000000021ff0238 
> 0000000040e89f10: 00000001009ca128 00000001009c9fdf 0000000022078920 0000000020c70cb0 00000000220b22a8 00000000220924a8 
> 0000000040e89f40: 0000000020c8bb48 0000000021ff0238 0000000022078920 0000000020c6ed78 00000001009c9c23 0000000020c6ee40 
> 0000000040e89f70: 0000000100000a45 000000000000001c 0000000021ff0238 0000000020c6ed78 0000000022078920 0000000021ff0238 
> 0000000040e89fa0: 00000001009c9b55 0000000020c137d8 00000001009c8e0f 0000000000000000 0000000022078920 0000000020b0b3b8 
> 0000000040e89fd0: 0000000021ff0238 0000000020c8b568 0000000000000000 0000000021ff0238 0000000020c137d8 0000000021ff0238 
> 0000000040e8a000: 0000000021ff0238 00000001009c8cb5 0000000020c0f3d8 00000001009c8bd4 0000000020c10a90 0000000003c064b0 
> 0000000040e8a030: 0000000021ff0238 0000000020c0f3d8 00000001009c8a8f 0000000003c057f0 0000000020a5ddb0 00000000220924a8 
> 0000000040e8a060: 00000001009c8296 0000000000000001 0000002a9b7aed08 000000010000090f 00000000005d7cd0 0000002a9b7aeed0 
> 0000000040e8a090: 00000000a6bf41f8 0000000020c0dca8 0000000021ff0238 0000000000000000 0000000020a5ddb0 0000000003bffb80 
> 0000000040e8a0c0: 0000000021ff0238 0000000000000000 0000000020a5ddb0 00000000220924a8 00000001009c7386 0000000020a5ddb0 
> 0000000040e8a0f0: 03c028209b7aed08 0000002a9b7aeed8 0000000020c0dca8 0000000000000000 00000000220924a8 0000000021ff0238 
> 0000000040e8a120: 0000000000000000 00000000220924a8 000000000000012c 0000002a9b7aeed0 0000000100000000 000000010002bdf0 
> 0000000040e8a150: 0000000020c08a38 0000000020a5ddb0 0000000100000a22 0000000003c00cf8 0000000000000001 00000000274b8c38 
> 0000000040e8a180: 0000000020c08a38 0000000021ff0238 00000001009c6da7 0000000100000a45 0000000020c0dca8 0000000021ff0238 
> 0000000040e8a1b0: 0000000000000000 0000000000000000 0000000021ff0238 00000001009c62a0 0000000021ff0238 0000000020c07368 
> 0000000040e8a1e0: 00000001009c612a 00000000005d7c90 0000000020c07368 0000000021ff0238 0000000021103b10 0000000000000000 
> 0000000040e8a210: 0000000021ff0238 0000000100000a45 000000000000001c 0000002a969f1010 0000000003bf6978 0000000020c05d48 
> 0000000040e8a240: 0000000021ff0238 00000001009c5b5f 0000000021ff0238 0000000000000000 0000000021ff4240 0000000020c05d48 
> 0000000040e8a270: 0000000021ff0238 0000000020b0b3b8 0000000021ff0238 00000001009c58b4 00000000210fb030 0000000040e8a3e0 
> 0000000040e8a2a0: 0000000020a5ddb0 00000001009c4f23 00000000269f9f90 0000000020b0b3b8 0000000021ff0238 0000000021033388 
> 0000000040e8a2d0: 0000010bf7bc5c80 00000000210fb030 0000002a00000001 0000000000000000 0000002a9b7aed08 0000002a956ad0b1 
> 0000000040e8a300: 000000000000029c 0000000002645f21 0000002a9b7aeec0 0000000040e8a598 0000000040e8a3e0 0000000040e8a560 
> 0000000040e8a330: 0000000100030068 0000000040e8a4f8 0000000040e8a3e0 00000001009c4b10 0000002a9b7aeb20 0000002a9b7aed08 
> 0000000040e8a360: 0000000000000001 0000000000000001 0000000040e8a3e0 0000002a9b7aed08 000000000064ca60 0000002a9560787a 
> 0000000040e8a390: 0000000000000002 0000002a956d3107 0000000103bb9370 000000000056aaa8 0000000040e8a500 0000002a9b7aee48 
> 0000000040e8a3c0: 0000002a9b7b3b00 0000002a956aca24 0000000003bb9370 0000000002643f80 0000002a9b7aee48 0000002a9b7aeec0 
> 0000000040e8a3f0: 0000000000000000 0000000100000000 0000000100000001 0000002a9b7aed28 0000000003bb9370 0000002a9b7aed08 
> 0000000040e8a420: 000000000056aaa8 0000000100000007 0000000200000001 0000000200000000 0000002a00000000 0000002a956c3228 
> 0000000040e8a450: 03bc261800000000 0000000002643f80 0000002a9b7aed08 0000002a9b7b3b00 0000002a9b7aee48 0000002a956c36f0 
> 0000000040e8a480: 0000000000000000 0000002a956c337c 0000002a956c36f0 0000000040e8a4f8 0000000040e8a500 0000000002643f80 
> 0000000040e8a4b0: 0000000000000001 0000002a9b7aee48 0000000000000000 0000002a9b7aed08 0000000002643f80 0000002a956c37c9 
> 0000000040e8a4e0: 011f3cc000000000 0000000040e8a4f8 000000010003af7a 0000002a9b7aeec8 0000000040e8a598 0000002a9b7aed08 
> 0000000040e8a510: 00000001001ecc8b 0000002a9b7aee58 0000002a9b7aeb20 0000000040e8a560 0000000000000001 0000000000000001 
> 0000000040e8a540: 0000002a9b7aed08 0000002a956cc14a 0000002a9b7aee48 000000010003c1e0 0000000000688b30 0000002a9b7aee48 
> 0000000040e8a570: 000000002192dec8 000000010003bfa7 0000000020b0b3b8 0000000021ff6d58 000000010003bea6 0000000021ff6be8 
> 0000000040e8a5a0: 0000000021ff6d58 0000000020b0b3b8 0000000021ff6be8 0000000100000001 0000000020b0b3b8 0000000020b0b3b8 
> 0000000040e8a5d0: 0000000021ff6be8 000000010005db3e 0000000021ff6be8 0000000021ff6d58 0000000020b0b3b8 0000000021ff6d98 
> 0000000040e8a600: 000000010003bd09 0000000021ff6be8 0000000021ff6be8 0000000021ff6be8 0000000020fa8d58 000000010003b2d5 
> 0000000040e8a630: 0000000021ff6be8 0000000020b0b3b8 0000000001939c68 0000000100003945 00000000200a1118 0000000025179958 
> 0000000040e8a660: 0000000000000001 000000000193de20 0000000021ff6c80 0000000020fa8d58 000000010023c5c8 0000000021ff6be8 
> 0000000040e8a690: 00000000ffffffff 0000000021ff6d10 0000000020ffd028 0000000021ff6c80 0000000020fa8d58 0000000020b0b3b8 
> Code:
> 00000001009ccdc8: 894890ff672533e8 c3d2f8252c8b48f3 0001025188b84803 ff6362c8e8000000 0e7ee82824748948 482824748b48ff67 
> 00000001009ccdf8: 00002a9b7ca2b8bf 26048b273c8b4800 7c8b48ff670fa3e8 0e16e826048b0824 0f0ee826048bff69 ee8948f78948ff67 
> 00000001009cce28: 90004d8b241c8948 50b848ff6bef21e8 9000000000010531 df8948ff63626be8 25048b4864f38948 28468948000000d8 
> 00000001009cce58: de8948ff647717e8 894890ff67249be8 ede81024748b48f3 85e8de8948ff6364 cccccccc90ff6724 8bfe8948f38948cf 
> 00000001009cce88: ffffffe0b848260c 480114ffffffffff 67b8c189c389de89 c1c889e9f7666666 89c2011fe8c104fa c82928c96bd189d8 
> 00000001009cceb8: 08768b48137fc085 1776084639d8f748 48c35b10c6748b48 127608463908768b 48c35b10c6748b48 000001009ccec6b8 
> 00000001009ccee8: 009cced6b848f400 ccccccf400000001 cccccccccccccccc 8b4840ec83485553 854820408b483846 4800000213840fc0 
> 00000001009ccf18: 4de838768b48f389 05e8f58948000002 8948c18948ff75bb 314830244c8948d8 44894838708b48db 0c8b20768b480824 
> 00000001009ccf48: e8ffff43e1e89026 24548b48ff63622c 89480824448b4830 244c8948ee8948f1 0093e910768b4828 8948304e8b480000 
> 00000001009ccf78: 8948d58948382474 8948cd2948302454 0c8b0824448948c6 48ffe4d635e89020 d53948d88948c289 480774c08548737c 
> 00000001009ccfa8: b84826eb38245c8b 00000000011df298 f38948ff6360f3e8 5c8948ff66b3dbe8 481024448b481024 48df894838245c8b 
> Loaded modules:
> (* denotes the module causing the exception)
> 0x400000-0x411037  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/bin/java
> 0x3a5dc00000-0x3a5dc0eff9  /lib64/tls/libpthread.so.0
> 0x3a5d400000-0x3a5d48459b  /lib64/tls/libm.so.6
> 0x3a5cf00000-0x3a5cf01c73  /lib64/libdl.so.2
> 0x3a5d100000-0x3a5d22ac59  /lib64/tls/libc.so.6
> 0x3a5cd00000-0x3a5cd1434f  /lib64/ld-linux-x86-64.so.2
> 0x2a95588000-0x2a957a660f  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit/libjvm.so
> 0x2a959e3000-0x2a959ecf13  /lib64/libnss_files.so.2
> 0x2a96c6f000-0x2a96c93473  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libjava.so
> 0x2a96d99000-0x2a96da5627  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libverify.so
> 0x3a62e00000-0x3a62e134eb  /lib64/libnsl.so.1
> 0x2a99d9f000-0x2a99db3fcf  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libnet.so
> 0x2a99eb6000-0x2a99ebed33  /lib64/libnss_nis.so.2
> 0x2a99fc0000-0x2a99fc38a3  /lib64/libnss_dns.so.2
> 0x3a5e200000-0x3a5e210d9b  /lib64/libresolv.so.2
> 0x2a9b5c8000-0x2a9b5c897b  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/librmi.so
> "RMI TCP Connection(4)-192.168.7" id=149 idx=0xc8 tid=1088993632 lastJavaFrame=(nil)
> Thread Stack Trace:
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Extended, platform specific info:
> libc release: 2.3.4-stable
> Elf headers:
> libc       ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5d11c4a0 PHOFF: 0x40 SHOFF: 0x13d5a8 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 69 STIDX: 66
> libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5dc05620 PHOFF: 0x40 SHOFF: 0x12980 EF: 0x0 HS: 64 PS: 56 PHN; 9 SS: 64 SHN: 38 STIDX: 35
> libjvm     ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x36c80 PHOFF: 0x40 SHOFF: 0x3106f0 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
> ===== END DUMP ===============================================================

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 14:11:39 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Thu, 14 Sep 2006 14:11:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-496) Sequential
 Accessor for the Action Language.
Message-ID: <10251090.1158257499132.JavaMail.jira@cloud.prod.atl2.jboss.com>

Sequential Accessor for the Action Language.
--------------------------------------------

                 Key: JBRULES-496
                 URL: http://jira.jboss.com/jira/browse/JBRULES-496
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1




-- 
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

        


From jira-events at jboss.com  Thu Sep 14 14:46:35 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 14:46:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-8) Port
 MarshalledValueIn(Out)putStream from aop
Message-ID: <14481718.1158259595983.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port MarshalledValueIn(Out)putStream from aop
---------------------------------------------

                 Key: JBCOMMON-8
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-8
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: core
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 2.0.0.Beta


A copy of AS/aop's MarshalledValueInputStream and MarshalledValueOutputStream should be added to common-core/org.jboss.util.stream.  These are prettyy straightforward extensions of the j2se ObjectStreams with only j2se dependencies.  Once a version of common with this in it is released, the other projects that use it can be converted.  Usages I'm aware of are:

AS via its version in the server module
AOP via its own version
JBoss Cache via dependency on the AS's jboss-minimal.jar

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 15:18:35 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 14 Sep 2006 15:18:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-88) Release 1.1 beta 2
Message-ID: <22904475.1158261515422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-88?page=all ]

Alejandro Guizar resolved BPEL-88.
----------------------------------

    Resolution: Done

Release posted to sourceforge and jboss labs:

http://labs.jboss.com/portal/jbossjbpm/downloads/bpel

> Release 1.1 beta 2
> ------------------
>
>                 Key: BPEL-88
>                 URL: http://jira.jboss.com/jira/browse/BPEL-88
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>
> The focus of this release is on time-driven activities: 
> a) <wait>
> b) <onAlarm> branches of <pick>
> c) <onAlarm> events in the <eventHandlers> section of scopes

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 15:22:38 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 15:22:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3656) Disconnect
 HAPartition channel upon failure in startService()
In-Reply-To: <12832750.1158180750351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28003950.1158261758406.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3656?page=all ]

Brian Stansberry updated JBAS-3656:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
         Priority: Critical  (was: Major)

> Disconnect HAPartition channel upon failure in startService()
> -------------------------------------------------------------
>
>                 Key: JBAS-3656
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3656
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> If an exception is thrown in ClusterPartition/HAPartition startService() after the channel is connected, the channel must be disconnected, or we've left a zombie member of the group.  Particularly in 4.0.x where the ServiceController will not undeploy a service that fails in start().
> Need to ensure stopService() properly handles a disconnected channel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 16:36:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 16:36:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3656) Disconnect
 HAPartition channel upon failure in startService()
In-Reply-To: <12832750.1158180750351.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19576296.1158266194448.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3656?page=all ]

Brian Stansberry closed JBAS-3656.
----------------------------------

    Resolution: Done

> Disconnect HAPartition channel upon failure in startService()
> -------------------------------------------------------------
>
>                 Key: JBAS-3656
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3656
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
> If an exception is thrown in ClusterPartition/HAPartition startService() after the channel is connected, the channel must be disconnected, or we've left a zombie member of the group.  Particularly in 4.0.x where the ServiceController will not undeploy a service that fails in start().
> Need to ensure stopService() properly handles a disconnected channel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:16:37 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 17:16:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3587) Add a system
 property to configure TCPPING.initial_hosts
In-Reply-To: <19247726.1156955263825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25009990.1158268597757.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3587?page=all ]

Brian Stansberry updated JBAS-3587:
-----------------------------------

        Summary: Add a system property to configure TCPPING.initial_hosts  (was: Add a startup switch to configure TCPPING.initial_hosts)
    Description: 
We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:

<TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...

For now I'm going to go with just a system property.  If people want a startup switch they can request it.

  was:
As discussed on conf call, we want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a startup switch and system property to allow this to be externalized from the xml file, e.g:

<TCPPING initial_hosts={${jboss.tcp.initial.hosts:localhost[7800]} ...

Should discuss on the forum whether we want a startup switch or just a property set via -D.  My preference is a switch.


> Add a system property to configure TCPPING.initial_hosts
> --------------------------------------------------------
>
>                 Key: JBAS-3587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1, JBossAS-4.0.6.CR1
>
>
> We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:
> <TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...
> For now I'm going to go with just a system property.  If people want a startup switch they can request it.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:28:38 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Thu, 14 Sep 2006 17:28:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-599) remoting doc does
 not cover enabling or configuring leasing from the client side
Message-ID: <30643037.1158269318956.JavaMail.jira@cloud.prod.atl2.jboss.com>

remoting doc does not cover enabling or configuring leasing from the client side
--------------------------------------------------------------------------------

                 Key: JBREM-599
                 URL: http://jira.jboss.com/jira/browse/JBREM-599
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: docs
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
            Priority: Minor
             Fix For: 2.2.0.Beta1 (Bluto)




-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:32:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 14 Sep 2006 17:32:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-5) Integrate OpenDS
 in HEAD testsuite
In-Reply-To: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25958031.1158269554419.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/SECURITY-5?page=comments#action_12343341 ] 
            
Anil Saldhana commented on SECURITY-5:
--------------------------------------

I have been able to bootstrap the DS via a MBean Service and also shutdown properly (except for a glitch). There is a OpenDS JMXConnectionHandler lurking around listening on port 1689 after the shutdown.

https://opends.dev.java.net/issues/show_bug.cgi?id=648

This is no big deal. But takes away the ability to continuosly start/stop the DS cleanly as part of test setup.

Workaround:
Make the start/stop of the DS as part of the server configuration "start/stop" and let the tests deal with adding ldifs and removing ldifs.

> Integrate OpenDS in HEAD testsuite
> ----------------------------------
>
>                 Key: SECURITY-5
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>
> My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule
> Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.
> My prelim testing details:
> ====================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
> [12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
>  Directory Server 0.1-build007 starting up."
> [12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
> database backend containing 1 entries has started."
> [12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
> msg="Access control has been disabled."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
> rectory Server has started successfully."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
> rectory Server has sent an alert notification generated by class org.opends.serv
> er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
> ert ID 458887):  The Directory Server has started successfully.."
> ================================================================================
> =============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
> -D "cn=Directory Manager" -w password -a -f a.ldif
> Processing ADD request for dc=jboss,dc=org.
> ADD operation successful for DN dc=jboss,dc=org.
> Processing ADD request for ou=People,dc=jboss,dc=org.
> ADD operation successful for DN ou=People,dc=jboss,dc=org.
> Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.
> ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.
> Processing ADD request for ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ===============================================================================
> ==============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
>  -b "dc=jboss,dc=org" -s sub "objectclass=*"
> dn: dc=jboss,dc=org
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o: JBoss
> dc: jboss
> dn: ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: person
> objectClass: uidObject
> userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
> cn: Java Duke
> sn: Duke
> uid: jduke
> =====================================================================================
> The application policy:
> <application-policy name = "jmx-console">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
>                           flag="required">
>                 <module-option name="java.naming.factory.initial"> 
>                     com.sun.jndi.ldap.LdapCtxFactory
>                     </module-option>
>                 <module-option name="java.naming.provider.url">
>                     ldap://localhost:389/
>                 </module-option>
>                 <module-option name="java.naming.security.authentication">
>                     simple
>                 </module-option>
>                 <module-option name="principalDNPrefix">uid=</module-option>                    
>                 <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
>                 <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
>                 <module-option name="uidAttributeID">member</module-option>
>                 <module-option name="matchOnUserDN">true</module-option>
>                 <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false</module-option>
>                 <module-option name="searchTimeLimit">5000</module-option>
>                 <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
>             </login-module>
>         </authentication>
>     </application-policy>

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:32:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 17:32:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3588) Add system property
 to configure multiplexer stack
In-Reply-To: <8708084.1156955383873.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14073117.1158269554537.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3588?page=all ]

Brian Stansberry closed JBAS-3588.
----------------------------------

    Resolution: Done

Property is jboss.multiplexer.stack.  Default is "udp"

> Add system property to configure multiplexer stack
> --------------------------------------------------
>
>                 Key: JBAS-3588
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3588
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> Add system property jboss.multiplexer.stack and use it in the various config files to select the stack.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:34:35 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 17:34:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3639) Lookup fails during
	failover
In-Reply-To: <8989834.1157983952060.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4724034.1158269675057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3639?page=all ]

Brian Stansberry resolved JBAS-3639.
------------------------------------

    Resolution: Rejected

Problem was the singleton was doing the lookup before the HA-JMS server had failed over and bound XAConnectionFactory.  Solved with a retry loop.

> Lookup fails during failover
> ----------------------------
>
>                 Key: JBAS-3639
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3639
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.6 Final, JBossAS-4.0.4RC1
>         Environment: jboss 3.2.6
> OS: SUSE LINUX 10
>            Reporter: Sangeetha Pisharody
>         Assigned To: Brian Stansberry
>
> I have a 4 node jboss(3.2.6) cluster. I have a test MBean that runs as a HASingleton on this cluster. All the test MBean does is lookup XAConnectionFactory. Here is the code that does the lookup
> Properties p = System.getProperties();
> p.put(Context.PROVIDER_URL, "localhost:1100");
> Context jndiContext = new InitialContext(p);
> jndiContext.lookup("XAConnectionFactory");
> I tried to stop jboss on the master node and this failed. During this period, another node tried to started this service and it could never get a XAConnectionFactory. This is the exception it threw
> javax.naming.NameNotFoundException: XAConnectionFactory
> at org.jboss.ha.jndi.TreeHead.lookup(TreeHead.java:237)
> at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:148)
> 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:324)
> at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:201)
> at $Proxy42.lookup(Unknown Source)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:621)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:583)
> at javax.naming.InitialContext.lookup(InitialContext.java:347)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.connectToMessageQueue(TestFailoverService.java:133)
> at com.racoman.ccc.mbeansUtils.jmsMonitorService.TestFailoverService.startSingleton(TestFailoverService.java:62)
> 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:324)
> at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:74)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:76)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:68)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:96)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:213)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:484)
> at org.jboss.ha.singleton.HASingletonController.invokeSingletonMBeanMethod(HASingletonController.java:207)
> at org.jboss.ha.singleton.HASingletonController.startSingleton(HASingletonController.java:144)
> at org.jboss.ha.singleton.HASingletonSupport.makeThisNodeMaster(HASingletonSupport.java:197)
> at org.jboss.ha.singleton.HASingletonSupport.partitionTopologyChanged(HASingletonSupport.java:133)
> at org.jboss.ha.jmx.HAServiceMBeanSupport$1.replicantsChanged(HAServiceMBeanSupport.java:211)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl.notifyKeyListeners(DistributedReplicantManagerImpl.java:780)
> at org.jboss.ha.framework.server.DistributedReplicantManagerImpl._remove(DistributedReplicantManagerImpl.java:587)
> 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:324)
> at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:236)
> at org.jboss.ha.framework.server.HAPartitionImpl.handle(HAPartitionImpl.java:898)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:615)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:512)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:326)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUp(MessageDispatcher.java:722)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.access$300(MessageDispatcher.java:554)
> at org.jgroups.blocks.MessageDispatcher$1.run(MessageDispatcher.java:691)
> at java.lang.Thread.run(Thread.java:534)
> This happened on our test cluster.
> On the production cluster, we saw a similar issue when because of a brief network issue the master failed over.
> Services that lookup XAConnectionFactory threw a similar exception.
> I tested with jboss 4.0.4 and the problem still exists

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:52:34 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 14 Sep 2006 17:52:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-679) Configurable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <11827703.1154619011320.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18430300.1158270754800.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-679?page=all ]

Bill Burke closed EJBTHREE-679.
-------------------------------

    Resolution: Done

open a different ticket if you need a furth extension please.  Thanks.

> Configurable default naming conventions for ejb3 jndi bindings
> --------------------------------------------------------------
>
>                 Key: EJBTHREE-679
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-679
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>         Assigned To: William DeCoste
>            Priority: Optional
>             Fix For: EJB 3.0 RC9 - FD
>
>
> An Interface could provide the default jndi bingings. A system property or an MBean could provide the implementation of this interface.
> By providing a naming convention, the RemoteBinding annotation of the ejb's could be omitted when there exist a naming convention so the deployment is simplified.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 17:52:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 14 Sep 2006 17:52:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-641) entitymanager is
 null then using @WebService and @Stateless annotations in one class
Message-ID: <2723765.1158270755289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-641?page=all ]

Bill Burke updated EJBTHREE-641:
--------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
                       (was: EJB 3.0 RC9 - FD)

> entitymanager is null then using @WebService and @Stateless annotations in one class
> ------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-641
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-641
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Ramil Israfilov
>             Fix For: EJB 3.0 RC10 - FD
>
>
> I have a class with both @Stateless and @WebService annotation and injected entitymanager:
> @WebService(name = "WebServiceTest", 
>         targetNamespace = "http://accesspoint.jc/server" )
> @SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
> @BindingType(value=javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
> @Remote(ServerInterface.class)
> public class Server implements ServerInterface {
>       @PersistenceContext(unitName="CertiOneAccessPoint")
> 	EntityManager em;
>     @WebMethod
>     public SessionResponse createSession(SessionRequest sessionRequest) {
>         log.debug("sessionRequest"+sessionRequest);
>         SessionResponse resp = new SessionResponse();
>         Session session = new Session();
>         session=(Session) em.persist(session);
>         resp.setSessionId(session.getId());
>         return resp;
>     }
> }
> I can successfully package and deploy EAR file.
> If I access EJB3 bean from remote application using JNDI lookup then everything works ok.
> But if I try to access webservice I got null pointer exception on line: session=(Session) em.persist(session);
> 2006-06-29 17:24:02,815 DEBUG [be.certipost.jc.accesspoint.server.impl.Server] sessionRequestbe.certipost.jc.accesspoint.server.SessionRequest at fbf04a
> 2006-06-29 17:24:02,815 ERROR [STDERR] java.lang.NullPointerException
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at be.certipost.jc.accesspoint.server.impl.Server.createSession(Server.java:51)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at java.lang.reflect.Method.invoke(Method.java:585)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.api.server.InstanceResolver$1.invoke(InstanceResolver.java:127)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:247)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.server.sei.SEIInvokerPipe.process(SEIInvokerPipe.java:97)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.protocol.soap.ServerMUPipe.process(ServerMUPipe.java:62)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.server.WSEndpointImpl$1.process(WSEndpointImpl.java:139)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:139)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:211)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:97)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:161)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:49)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 2006-06-29 17:24:02,815 ERROR [STDERR] 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 2006-06-29 17:24:02,831 ERROR [STDERR] 	at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 18:30:35 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 18:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3587) Add a system
 property to configure TCPPING.initial_hosts
In-Reply-To: <19247726.1156955263825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14809038.1158273035602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3587?page=all ]

Brian Stansberry updated JBAS-3587:
-----------------------------------

    Fix Version/s:     (was: JBossAS-4.0.6.CR1)

Only for 5.0 as this kind of config only makes sense with the multiplexer.  If two separate TCP channels used the same property, that would make a mess.  

For 4.0.x users of course can create their own property and add it to their config files; we just won't ship with the config files already set up that way.

> Add a system property to configure TCPPING.initial_hosts
> --------------------------------------------------------
>
>                 Key: JBAS-3587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:
> <TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...
> For now I'm going to go with just a system property.  If people want a startup switch they can request it.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 20:58:35 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 14 Sep 2006 20:58:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-702) Quartz Timer
 Service in E-EJB3 hangs process, exception on shutdown
Message-ID: <1150389.1158281915419.JavaMail.jira@cloud.prod.atl2.jboss.com>

Quartz Timer Service in E-EJB3 hangs process, exception on shutdown
-------------------------------------------------------------------

                 Key: EJBTHREE-702
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-702
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC8 - FD
            Reporter: Bill Burke
         Assigned To: Carlo de Wolf
             Fix For: EJB 3.0 RC10 - FD


to test this out:

build embedded.dist
go run one of the tutorials.  You will see that the applicatoin will never exit.  I'm guessing this is becuase a Quartz thread is a non-daemon thread and holding up the exit of the process.  Also there is a NullPointerException on shutdown.  I have disabled the Quartz Timer Service in embedded-jboss-beans.xml for now.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 22:33:40 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Thu, 14 Sep 2006 22:33:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (EJBTHREE-703) <security-domain>
 setting in
 deployment descriptor populates @SecurityDomain annotation incorrectly on
 EJB3 session beans
In-Reply-To: <12582259.1157495069506.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5539658.1158287620175.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-703?page=all ]

Scott M Stark moved JBAS-3624 to EJBTHREE-703:
----------------------------------------------

              Project: EJB 3.0  (was: JBoss Application Server)
                  Key: EJBTHREE-703  (was: JBAS-3624)
          Component/s:     (was: EJB3)
    Affects Version/s:     (was: JBossAS-4.0.4.GA)

> <security-domain> setting in deployment descriptor populates @SecurityDomain annotation incorrectly on EJB3 session beans
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-703
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-703
>             Project: EJB 3.0
>          Issue Type: Bug
>            Reporter: David Green
>         Assigned To: Bill Burke
>
> Specifying a <security-domain> in the jboss-app.xml incorrectly sets the @SecurityDomain on EJB3 session beans.
> In the jboss-app.xml the security domain is specified as follows:
> <jboss-app>
> 	<security-domain>java:/jaas/hch</security-domain>
> </jboss-app>
> In Ejb3DescriptorHandler the security-domain is copied directly into the SecurityDomainImpl instance as "java:/jaas/hch", however the @SecurityDomain annotation should be populated with the value "hch" (without the leading "java:/jaas/" prefix).  This causes the EJB3 session bean authentication to behave unexpectedly, since the authentication for the bean reverts to the default domain instead of the specified one.
> The only way I've found to workaround this issue is to specify the @SecurityDomain individually on every session bean in the project.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 22:49:34 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Thu, 14 Sep 2006 22:49:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-364) Secured JBoss
 server configured via 'JBoss Server View' fail to Start/Debug
In-Reply-To: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2758406.1158288574034.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-364?page=comments#action_12343348 ] 
            
Robert Stryker commented on JBIDE-364:
--------------------------------------

A Twiddle launch tab has been added to the server's launch configuration so that user/pass can be added to execution arguments. 

> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-364
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200
> JBoss-4.0.4.GA
> jdk1.5.0_06
> MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
> jmx-console also secured with the same security Domain.
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>
> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
> - MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
> has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
>    <descriptors>
>       <interceptors>
>          <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
>             securityDomain="java:/jaas/jmx-console"/>
>       </interceptors>
>    </descriptors>
> Im assuming that the 'jmx-console' is also secured with the same security Domain.
> Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
> on the server.

-- 
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

       



From jira-events at jboss.com  Thu Sep 14 22:51:34 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Thu, 14 Sep 2006 22:51:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-364) Secured JBoss server
 configured via 'JBoss Server View' fail to Start/Debug
In-Reply-To: <26053231.1157722169068.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30660994.1158288694085.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-364?page=all ]

Robert Stryker closed JBIDE-364.
--------------------------------

    Fix Version/s: 2.0.0.Beta3
       Resolution: Done

> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug
> ---------------------------------------------------------------------------
>
>                 Key: JBIDE-364
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-364
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200
> JBoss-4.0.4.GA
> jdk1.5.0_06
> MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService (jmx-invoker-service.xml) <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor" securityDomain="java:/jaas/jmx-console"/>
> jmx-console also secured with the same security Domain.
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>             Fix For: 2.0.0.Beta3
>
>
> Secured JBoss server configured via 'JBoss Server View' fail to Start/Debug when:
> - MBean: org.jboss.jmx.connector.invoker.InvokerAdaptorService
> has the security domain configured via uncomment ($JBOSS_HOME/server/x/deploy/jmx-invoker-service.xml):
>    <descriptors>
>       <interceptors>
>          <interceptor code="org.jboss.jmx.connector.invoker.AuthenticationInterceptor"
>             securityDomain="java:/jaas/jmx-console"/>
>       </interceptors>
>    </descriptors>
> Im assuming that the 'jmx-console' is also secured with the same security Domain.
> Posible cause: Access to server status via twiddle script (?JBossAS Adapter?) doesn't use user/password options to manage authentication 
> on the server.

-- 
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

       



From jira-events at jboss.com  Thu Sep 14 22:51:34 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Thu, 14 Sep 2006 22:51:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBIDE-303) Custom JBoss
 configuration wizard (ala JBoss installer)
Message-ID: <26003123.1158288694247.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-303?page=all ]

Robert Stryker closed JBIDE-303.
--------------------------------

    Resolution: Rejected

Feature decided against. 

> Custom JBoss configuration wizard (ala JBoss installer)
> -------------------------------------------------------
>
>                 Key: JBIDE-303
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-303
>             Project: JBoss IDE
>          Issue Type: Feature Request
>          Components: JBossAS Adapter
>            Reporter: Marshall Culpepper
>         Assigned To: Robert Stryker
>            Priority: Minor
>             Fix For: 2.0.0.GA
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Create a configuration wizard similar to the JBoss installation wizard that would allow the user to create a custom JBoss configuration from a standard JBoss installation.
> Some ideas:
> - Automatically secure jmx/admin consoles
> - install/don't install certain services

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 23:05:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 23:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
Message-ID: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>

JDBCCacheLoader should not directly serialize a map passed to put
-----------------------------------------------------------------

                 Key: JBCACHE-769
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 1.4.0.SP1, 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.2.4SP2, 1.2.4SP1, 1.2.4, 1.2.3
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
            Priority: Minor


If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.

Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.

Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.

The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Thu Sep 14 23:33:34 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 14 Sep 2006 23:33:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30140479.1158291214382.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Fix Version/s: 2.0.0
         Assignee: Brian Stansberry  (was: Manik Surtani)

JDBCCacheLoader is fixed; need to check the other cache loaders.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 00:55:34 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 15 Sep 2006 00:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1039) Producer NPE
 when no namespace prefix is provided in RuntimeContext.
Message-ID: <1442646.1158296134469.JavaMail.jira@cloud.prod.atl2.jboss.com>

Producer NPE when no namespace prefix is provided in RuntimeContext.
--------------------------------------------------------------------

                 Key: JBPORTAL-1039
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1039
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1


When creating the WindowContext for the invocation in MarkupHandler, we are relying on the precense of namespacePrefix in the passed RuntimeContext. NamespacePrefix is optional in WSRP 1.0.
On the flip side, we should also provide that information when creating markup requests on the Consumer.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 00:55:34 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 15 Sep 2006 00:55:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1039) Producer NPE
 when no namespace prefix is provided in RuntimeContext.
In-Reply-To: <1442646.1158296134469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22566037.1158296134547.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1039?page=all ]

Chris Laprun updated JBPORTAL-1039:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89851

> Producer NPE when no namespace prefix is provided in RuntimeContext.
> --------------------------------------------------------------------
>
>                 Key: JBPORTAL-1039
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1039
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>
> When creating the WindowContext for the invocation in MarkupHandler, we are relying on the precense of namespacePrefix in the passed RuntimeContext. NamespacePrefix is optional in WSRP 1.0.
> On the flip side, we should also provide that information when creating markup requests on the Consumer.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 01:35:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 01:35:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-319) -props ./udp.xml
 finds udp.xml in classpath *before* file ./udp.xml
Message-ID: <25571427.1158298534007.JavaMail.jira@cloud.prod.atl2.jboss.com>

-props ./udp.xml finds udp.xml in classpath *before* file ./udp.xml
-------------------------------------------------------------------

                 Key: JGRP-319
                 URL: http://jira.jboss.com/jira/browse/JGRP-319
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


If we explicitly define a relative path for a config file, then we must honor it, so find ./udp.xml *before* udp.xml in the classpath

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 01:43:34 2006
From: jira-events at jboss.com (Sohui Gu (JIRA))
Date: Fri, 15 Sep 2006 01:43:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29061995.1158299014677.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=comments#action_12343352 ] 
            
Sohui Gu commented on JBSEAM-347:
---------------------------------

[#|2006-09-15T13:25:27.468+0800|SEVERE|sun-appserver-pe8.2|org.apache.pluto.invoker.impl.PortletInvokerImpl|_ThreadID=16;|PortletInvokerImpl.render() - Error while dispatching portlet.
javax.portlet.PortletException: java.lang.IllegalStateException: No active conversation context
	at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:341)
	at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:205)
	at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:145)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:140)
	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.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
	at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:105)
	at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
	at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
	at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:75)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:159)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:281)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)
	at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)
	at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)
Caused by: javax.faces.el.EvaluationException: java.lang.IllegalStateException: No active conversation context
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:206)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:154)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:753)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:728)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:278)
	at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:59)
	at com.sun.faces.portlet.ViewHandlerImpl.renderView(ViewHandlerImpl.java:132)
	at com.sun.faces.portlet.LifecycleImpl$RenderResponsePhase.execute(LifecycleImpl.java:702)
	at com.sun.faces.portlet.LifecycleImpl.phase(LifecycleImpl.java:323)
	at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:244)
	at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:327)
	... 171 more
Caused by: java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Process.instance(Process.java:32)
	at org.jboss.seam.core.TaskInstance.instance(TaskInstance.java:51)
	at org.jboss.seam.contexts.BusinessProcessContext.getTaskInstance(BusinessProcessContext.java:213)
	at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:51)
	at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:155)
	at org.jboss.seam.Component.getInstance(Component.java:1245)
	at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
	at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
	at com.sun.faces.el.impl.NamedValue.evaluate(NamedValue.java:125)
	at com.sun.faces.el.impl.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:243)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:173)
	... 181 more

Nested Exception is javax.faces.el.EvaluationException: java.lang.IllegalStateException: No active conversation context
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:206)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:154)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:753)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.pageBean(ViewHandlerImpl.java:728)
	at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.renderView(ViewHandlerImpl.java:278)
	at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:59)
	at com.sun.faces.portlet.ViewHandlerImpl.renderView(ViewHandlerImpl.java:132)
	at com.sun.faces.portlet.LifecycleImpl$RenderResponsePhase.execute(LifecycleImpl.java:702)
	at com.sun.faces.portlet.LifecycleImpl.phase(LifecycleImpl.java:323)
	at com.sun.faces.portlet.LifecycleImpl.render(LifecycleImpl.java:244)
	at com.sun.faces.portlet.FacesPortlet.render(FacesPortlet.java:327)
	at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:205)
	at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:145)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:140)
	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.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
	at org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
	at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:105)
	at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
	at org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
	at org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:66)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:75)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.jsp.WEB_002dINF.aggregation.RootFragment_jsp._jspService(RootFragment_jsp.java:159)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:105)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:336)
	at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:297)
	at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:247)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:599)
	at org.apache.catalina.core.ApplicationDispatcher.access$100(ApplicationDispatcher.java:80)
	at org.apache.catalina.core.ApplicationDispatcher$PrivilegedInclude.run(ApplicationDispatcher.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:509)
	at org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
	at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:281)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:860)
	at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:249)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
	at org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:282)
	at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:165)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:257)
	at org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:55)
	at org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:161)
	at java.security.AccessController.doPrivileged(Native Method)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:263)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:225)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:173)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:132)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:551)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:933)
	at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:189)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.doProcess(ProcessorTask.java:604)
	at com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:475)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:371)
	at com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:264)
	at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:281)
	at com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:83)
Caused by: java.lang.IllegalStateException: No active conversation context
	at org.jboss.seam.core.Process.instance(Process.java:32)
	at org.jboss.seam.core.TaskInstance.instance(TaskInstance.java:51)
	at org.jboss.seam.contexts.BusinessProcessContext.getTaskInstance(BusinessProcessContext.java:213)
	at org.jboss.seam.contexts.BusinessProcessContext.get(BusinessProcessContext.java:51)
	at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:155)
	at org.jboss.seam.Component.getInstance(Component.java:1245)
	at org.jboss.seam.jsf.SeamVariableResolver.resolveVariable(SeamVariableResolver.java:44)
	at org.apache.myfaces.config.LastVariableResolverInChain.resolveVariable(LastVariableResolverInChain.java:42)
	at com.sun.faces.el.impl.NamedValue.evaluate(NamedValue.java:125)
	at com.sun.faces.el.impl.ExpressionEvaluatorImpl.evaluate(ExpressionEvaluatorImpl.java:243)
	at com.sun.faces.el.ValueBindingImpl.getValue(ValueBindingImpl.java:173)
	... 181 more
|#]


> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 02:17:33 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Fri, 15 Sep 2006 02:17:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3494) failure in
 org.jboss.test.classloader.test.BasicLoaderUnitTestCase
In-Reply-To: <9114975.1155051432724.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2442603.1158301053366.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3494?page=all ]

Scott M Stark closed JBAS-3494.
-------------------------------

    Resolution: Done

It was just an issue with when the method signature classes were loaded. Just invoking getMethods under jrockit was not loading the method throws classes. The test was updated to explicitly attempt to obtain the exception clause classes.

> failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> ------------------------------------------------------------------
>
>                 Key: JBAS-3494
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3494
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite, ClassLoading
>         Environment: linux - dev03 in qa,  java version "1.4.2_11" - jrockit
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a failure in org.jboss.test.classloader.test.BasicLoaderUnitTestCase
> junit.framework.AssertionFailedError: Should not have gotten ExThrower methods
> 	at org.jboss.test.classloader.test.BasicLoaderUnitTestCase.testNoClassDefFoundError2(BasicLoaderUnitTestCase.java:109)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> There is no associated server log

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 02:37:35 2006
From: jira-events at jboss.com (Uhyon Chung (JIRA))
Date: Fri, 15 Sep 2006 02:37:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-750) NPE on
 TaskInstance.java on end()
 when TaskInstance created manually and no Task is assigned
Message-ID: <30850656.1158302255345.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE on TaskInstance.java on end() when TaskInstance created manually and no Task is assigned
--------------------------------------------------------------------------------------------

                 Key: JBPM-750
                 URL: http://jira.jboss.com/jira/browse/JBPM-750
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: All
            Reporter: Uhyon Chung
         Assigned To: Tom Baeyens


When you create a new TaskInstance manually (from a ActionHandler) without a Task assigned, an NPE occurs in a log statement in the end(Transition) method.

If you take a look at the end method, it seems to allow null tasks, because it checks whether the task is null before execution methods on the task field. However, in the log.debug statement, it does not do this null check, which causes an NPE. I'm not quite sure if having a TaskInstance without a Task is really a good practice, but otherwise I would need to create a Task object and add it to the ProcessDefinition, which is definitely not something I want to be doing since I just want to add a task instance to the user's task list dynamically.

I've created a small fix, and the patch is as follows.I made the patch based on the 3.1.2 on CVS using Eclipse patch.


### Eclipse Workspace Patch 1.0
#P jbpm3
Index: jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java
===================================================================
RCS file: /cvsroot/jbpm/jbpm.3/jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java,v
retrieving revision 1.6
diff -u -r1.6 TaskInstance.java
--- jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java	8 Sep 2006 11:23:07 -0000	1.6
+++ jpdl/jar/src/main/java/org/jbpm/taskmgmt/exe/TaskInstance.java	15 Sep 2006 06:27:07 -0000
@@
         if (transition==null) {
-          log.debug("completion of task '"+task.getName()+"' results in taking the default transition");
+          log.debug("completion of task '"+(task==null?getName():task.getName())+"' results in taking the default transition");
           token.signal();
         } else {
-          log.debug("completion of task '"+task.getName()+"' results in taking transition '"+transition+"'");
+          log.debug("completion of task '"+(task==null?getName():task.getName())+"' results in taking transition '"+transition+"'");
           token.signal(transition);
         }
       }
 -464,10 +464,10 @@
          ) {

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 03:21:35 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Fri, 15 Sep 2006 03:21:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (BPEL-186) Write a blog entry
 about the beta release
Message-ID: <10190413.1158304895499.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/BPEL-186?page=comments#action_12343355 ] 
            
Alejandro Guizar commented on BPEL-186:
---------------------------------------

Blog published: http://tinyurl.com/hjj4c

> Write a blog entry about the beta release
> -----------------------------------------
>
>                 Key: BPEL-186
>                 URL: http://jira.jboss.com/jira/browse/BPEL-186
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 03:37:34 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Fri, 15 Sep 2006 03:37:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-122) Links should be
	recognized
Message-ID: <8232553.1158305854518.JavaMail.jira@cloud.prod.atl2.jboss.com>

Links should be recognized
--------------------------

                 Key: JBFORUMS-122
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-122
             Project: JBoss Forums
          Issue Type: Feature Request
          Components: Forum Enhancements
            Reporter: Thomas Diesler
         Assigned To: Sohil Shah


Instead of 

[url]http://jira.jboss.com/jira/secure/CreateIssue.jspa[/url]

I like to simply use

http://jira.jboss.com/jira/secure/CreateIssue.jspa

There are a lot of user provided links that I cannot click on.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 04:41:36 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 04:41:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-704) Missing
 privileged action to get Principal
Message-ID: <23329041.1158309696237.JavaMail.jira@cloud.prod.atl2.jboss.com>

Missing privileged action to get Principal 
-------------------------------------------

                 Key: EJBTHREE-704
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-704
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Roland R?z


The method  org.jboss.ejb3.BaseSessionContext.getCallerPrincipal should use a privileged action  instead of SecurityAssociation.getCallerPrincipal(). 

@see http://jira.jboss.com/jira/browse/JBAOP-95


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 04:43:35 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 04:43:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-705) Pluggable default
 naming conventions for ejb3 jndi bindings
Message-ID: <1871287.1158309815074.JavaMail.jira@cloud.prod.atl2.jboss.com>

Pluggable default naming conventions for ejb3 jndi bindings
-----------------------------------------------------------

                 Key: EJBTHREE-705
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-705
             Project: EJB 3.0
          Issue Type: Feature Request
            Reporter: Roland R?z
            Priority: Minor


Currently the org.jboss.ejb3.ProxyFactoryHelper uses the [<earname>/]<ejbname>/[remote|local] naming convention. 

An Interface could provide the default names for jndi binding when the deployer doesn't provide them.

The interface could look like this: 

public interface DefaultJndiNameProvider { 
   String getDefaultRemoteJndiName(Container container); 
   String getDefaultLocalJndiName(Container container); 
} 


The implementation of the DefaultJndiNameProvider could be configured using a System Property.


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 05:13:42 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 15 Sep 2006 05:13:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBRULES-495) Allows for
 automatic meta data
 gathering during rule/rule package saves to repository
In-Reply-To: <32823093.1158253481712.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11206429.1158311622136.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-495?page=all ]

Michael Neale reassigned JBRULES-495:
-------------------------------------

    Assignee: Michael Neale  (was: Mark Proctor)

> Allows for automatic meta data gathering during rule/rule package saves to repository
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-495
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-495
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Marcos Tengelmann
>         Assigned To: Michael Neale
>            Priority: Optional
>
> In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.
> The whole idea here is to keep the concept of Category only for business purposes.
> Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions
> With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 05:15:37 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 05:15:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-705) Pluggable
 default naming conventions for ejb3 jndi bindings
In-Reply-To: <1871287.1158309815074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28273567.1158311737967.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-705?page=comments#action_12343357 ] 
            
Roland R?z commented on EJBTHREE-705:
-------------------------------------

We need a different naming convention to support multiple jboss instances which can use services from each other. The instances are linked to each other using jndi links und rely on naming conventions. 

With a pluggable jndi name provider we could get rid of the "pain" from configuring the jndi name for each bean. It would be fine when the "Configuration by Exception" rule applies also in more complex environments.


> Pluggable default naming conventions for ejb3 jndi bindings
> -----------------------------------------------------------
>
>                 Key: EJBTHREE-705
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-705
>             Project: EJB 3.0
>          Issue Type: Feature Request
>            Reporter: Roland R?z
>            Priority: Minor
>
> Currently the org.jboss.ejb3.ProxyFactoryHelper uses the [<earname>/]<ejbname>/[remote|local] naming convention. 
> An Interface could provide the default names for jndi binding when the deployer doesn't provide them.
> The interface could look like this: 
> public interface DefaultJndiNameProvider { 
>    String getDefaultRemoteJndiName(Container container); 
>    String getDefaultLocalJndiName(Container container); 
> } 
> The implementation of the DefaultJndiNameProvider could be configured using a System Property.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 05:17:46 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 15 Sep 2006 05:17:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-495) Allows for
 automatic meta
 data gathering during rule/rule package saves to repository
In-Reply-To: <32823093.1158253481712.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25167803.1158311866363.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-495?page=comments#action_12343358 ] 
            
Michael Neale commented on JBRULES-495:
---------------------------------------

This woudl apply to any rule change/save. 

The meta data would need to be refreshed.

We could use a structure like

     RuleNode
   /                  
ColumnNode      
-field list (String[])
-name

> Allows for automatic meta data gathering during rule/rule package saves to repository
> -------------------------------------------------------------------------------------
>
>                 Key: JBRULES-495
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-495
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-brms
>            Reporter: Marcos Tengelmann
>         Assigned To: Michael Neale
>            Priority: Optional
>
> In order to make search easy as possible, we would like to have automatic meta data collected during the process of importing rules from files or during the save process from UI, to repository back end.
> The whole idea here is to keep the concept of Category only for business purposes.
> Besides the category concept , we could have attributes set into the repository attached with its components. With that we mean, that we could automatically (The saver to repository is a suggesiton on doing this), to extract Columns (Could be OTN also?) from rules, and create lists of all column types a given rule uses and even other type of data could be extracted from rule files and definitions
> With that we could be able to link in searches, business desciptions and categories to real implementation, giving very usefull results (A Better search engine than Google)....

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 06:42:41 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Fri, 15 Sep 2006 06:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11240801.1158316961975.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=comments#action_12343359 ] 
            
Manik Surtani commented on JBCACHE-769:
---------------------------------------

Do we want to backport this for 1.4.x as well?

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 07:04:36 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Fri, 15 Sep 2006 07:04:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-497) Joda datetime API
	integration
Message-ID: <32125869.1158318276385.JavaMail.jira@cloud.prod.atl2.jboss.com>

Joda datetime API integration
-----------------------------

                 Key: JBRULES-497
                 URL: http://jira.jboss.com/jira/browse/JBRULES-497
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: All
            Reporter: Michael Neale
         Assigned To: Mark Proctor


http://joda-time.sourceforge.net/userguide.html

Would be VERY nice to have this working at the parser level to parser dates in a string, but also possibly in our expression language to overload "+", "-" etc for subtracting dates/fragments of dates:

eg:

today - "6Months" 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:08:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 08:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-320)
 ConnectionTable/ConnectionTableNIO
 have leftover threads after stop()
Message-ID: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>

ConnectionTable/ConnectionTableNIO have leftover threads after stop()
---------------------------------------------------------------------

                 Key: JGRP-320
                 URL: http://jira.jboss.com/jira/browse/JGRP-320
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


Unit test ConnectionTableTest shows this.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:08:33 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 08:08:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21076134.1158322113915.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-320?page=comments#action_12343362 ] 
            
Bela Ban commented on JGRP-320:
-------------------------------

ConnectionTable has been fixed.
ConnectionTableNIO still fails if the sleep(1000) towards the end of the method is removed

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:22:33 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:22:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3643) null message blob is
 created in
 the jms_messages table which leads to PersistenceManager fail to restore
 queue during restart
In-Reply-To: <13861984.1158018089604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9858717.1158322953967.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3643?page=all ]

Adrian Brock closed JBAS-3643.
------------------------------

    Resolution: Duplicate Issue

No, you can use search just as well as I can.
All this post does is pollute that search index. I will delete it in a few days.

> null message blob is created in the jms_messages table which leads to PersistenceManager fail to restore queue during restart
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3643
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3643
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Windows XP, Oracle 9.2.0.5
>            Reporter: Edward Lu
>            Priority: Critical
>
> A null blob is inserted into the jms_message table as a result of sending message (greater than 4k messages) to jms queue.  The Oracle jdbc persistence manager is deployed in our environment as JMS queue persistence mechanism.  As a result, when JBoss is restarted, the persistence manager could not restore queue since there is null blob in the jms_messages table (please see the following stack traces and sqlplus output):
> I did a quick search and found that JBAS-2503 indicates the Oracle 4k limit problem should be resolved with JBossAS-4.0.4 GA.   But I did run into the above problem with JBossAS-4.0.4 GA version.
> Your help is highly appreciated.
> ****************************************************************************************
> SQL> select count(*) from jms_messages where messageblob is null;
>   COUNT(*)
> ----------
>          3
> *******************************************************************************************
> 2006-09-11 15:56:43,447 WARN  [ServiceController]  - Problem starting service jboss.mq.destination:name=edAuditQueue,service=Queue^M
> org.jboss.mq.SpyJMSException: Unexpected error in recovery; - nested throwable:
> (java.lang.NullPointerException)^M
>         at org.jboss.mq.SpyJMSException.getAsJMSException(SpyJMSException.java:78)^M
>         at org.jboss.mq.SpyJMSException.rethrowAsJMSException(SpyJMSException.java:63)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:525)^M
>         at org.jboss.mq.server.JMSQueue.<init>(JMSQueue.java:65)^M
>         at org.jboss.mq.server.jmx.Queue.startService(Queue.java:78)^M
> ......
> ......
> Caused by: java.lang.NullPointerException^M
>         at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2150)^M
>         at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2163)^M
>         at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2631)^M
>         at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)^M
>         at java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.extractMessage(PersistenceManager.java:665)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.internalRestoreQueue(PersistenceManager.java:556)^M
>         at org.jboss.mq.pm.jdbc2.PersistenceManager.restoreQueue(PersistenceManager.java:514)^M
> *******************************************************************************************************************

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:24:34 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 08:24:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-320)
 ConnectionTable/ConnectionTableNIO
 have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18671278.1158323074048.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-320?page=all ]

Bela Ban updated JGRP-320:
--------------------------

    Description: 
Unit test ConnectionTableTest shows this, use the following system properties:
-Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]


  was:Unit test ConnectionTableTest shows this.


> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:26:33 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:26:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2566) Remove public
 interface changes from HEAD
Message-ID: <6333807.1158323193352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2566?page=all ]

Adrian Brock closed JBAS-2566.
------------------------------

    Resolution: Done
      Assignee: Adrian Brock  (was: Elias Ross)

No, I fixed this in the latest synchronization of the 4.0.x and 5.0.x trees.
This removed the addition of the ThreadPool to the invoker/interceptor interfaces
which should be handled in the same way as the 
org.jboss.mq.Recoverable interface I added.

> Remove public interface changes from HEAD
> -----------------------------------------
>
>                 Key: JBAS-2566
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2566
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Elias Ross
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:28:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:28:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2575) Hibernate usage in
	JBoss Messaging
Message-ID: <6076094.1158323316492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2575?page=all ]

Adrian Brock closed JBAS-2575.
------------------------------

    Resolution: Rejected

Steve, you need to reopen this issue in the messaging project.
I cannot move this issue there since it is a subtask?

> Hibernate usage in JBoss Messaging
> ----------------------------------
>
>                 Key: JBAS-2575
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2575
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Steve Ebersole
>         Assigned To: Steve Ebersole
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Currently, JBoss Messaging is going down the path of pluggable "persistence managers" attempted by JBossMQ in order to achieve database portability.  As discussed numerous times, we should introduce Hibernate here to achieve this portability rather than maintaining all this stuff for the various databases.  Plus would give Messaging a much easier way to introduce some of the other benefits/features of using Hibernate (caching, 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

        


From jira-events at jboss.com  Fri Sep 15 08:30:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-2575) Hibernate usage in
 JBoss Messaging
Message-ID: <16864766.1158323435016.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2575?page=all ]

Adrian Brock reopened JBAS-2575:
--------------------------------

             

> Hibernate usage in JBoss Messaging
> ----------------------------------
>
>                 Key: JBAS-2575
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2575
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Steve Ebersole
>         Assigned To: Steve Ebersole
>
> Currently, JBoss Messaging is going down the path of pluggable "persistence managers" attempted by JBossMQ in order to achieve database portability.  As discussed numerous times, we should introduce Hibernate here to achieve this portability rather than maintaining all this stuff for the various databases.  Plus would give Messaging a much easier way to introduce some of the other benefits/features of using Hibernate (caching, 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

        


From jira-events at jboss.com  Fri Sep 15 08:30:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:30:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2575) Hibernate usage in
	JBoss Messaging
Message-ID: <4070594.1158323435144.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2575?page=all ]

Adrian Brock closed JBAS-2575.
------------------------------

    Fix Version/s:     (was: JBossAS-5.0.0.Beta)
       Resolution: Rejected

> Hibernate usage in JBoss Messaging
> ----------------------------------
>
>                 Key: JBAS-2575
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2575
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Steve Ebersole
>         Assigned To: Steve Ebersole
>
> Currently, JBoss Messaging is going down the path of pluggable "persistence managers" attempted by JBossMQ in order to achieve database portability.  As discussed numerous times, we should introduce Hibernate here to achieve this portability rather than maintaining all this stuff for the various databases.  Plus would give Messaging a much easier way to introduce some of the other benefits/features of using Hibernate (caching, 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

        


From jira-events at jboss.com  Fri Sep 15 08:34:37 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:34:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3091) Session recycle bug in
 org.jboss.jms.asf.StdServerSession
Message-ID: <28297136.1158323677058.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3091?page=all ]

Adrian Brock closed JBAS-3091.
------------------------------

    Fix Version/s:     (was: JBossAS-4.0.6.CR1)
       Resolution: Won't Fix

This issue is replaced by the rewrite of the session pool on the linked task.

> Session recycle bug in org.jboss.jms.asf.StdServerSession
> ---------------------------------------------------------
>
>                 Key: JBAS-3091
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3091
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Roland R?z
>
> If a JMS provider throws an unchecked Exception out of Session.run(), the method org.jboss.jms.asf.StdServerSession.run() does recycled the Session without making a rollback on the Session before. If the next message on this recycled Session will be commited the older Message which has been already consumed from the Messaging System before when throwing the Exception will be lost. Because of the Exception this older Message has neither been rollbacked nor committed before.
> To avoid this problem a Session.rollback() needs to be called before recycling it in case of any unchecked Exception. (See code snippet below!)
> Possible Fix:
> public void run()
>    {
>       boolean trace = log.isTraceEnabled();
>       if (trace)
>          log.trace("running...");
>       try
>       {
>          if (xaSession != null)
>             xaSession.run();
>          else
>             session.run();
>       }      
>       // To avoid loosing Messages rollback the Session in case of any Exception from the JMS provider
>       catch (Throwable e) {
>           log.error("Exception occured during the Session.run(). Call Session.rollback() before recycling it.", e);
>           try {
>               if (xaSession != null)
>                   xaSession.rollback();
>                else
>                   session.rollback();
>           }
>           catch (JMSException ex) {
>               log.error("Exception occured when calling Session.rollback()", e);
>           }
>       }
>       finally
>       {
>          if (trace)
>             log.trace("recycling...");
>         
>          recycle();
>          if (trace)
>             log.trace("finished run");
>       }
>    }

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:36:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2409) EJB3 JMS Integration
Message-ID: <16868672.1158323795166.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2409?page=all ]

Adrian Brock reassigned JBAS-2409:
----------------------------------

    Assignee: William DeCoste

Assigned to Bill to update the status.

> EJB3 JMS Integration
> --------------------
>
>                 Key: JBAS-2409
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2409
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>         Assigned To: William DeCoste
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Need to determine whether the legacy JMS MDB integration using ServerSessionPools directly
> needs to be refactored to cover both EJB2.1 and EJB3.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

        


From jira-events at jboss.com  Fri Sep 15 08:36:35 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:36:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2150) Disable automatic
 JBossMQ destination construction
Message-ID: <16504128.1158323795295.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2150?page=all ]

Adrian Brock updated JBAS-2150:
-------------------------------

    Comment: was deleted

> Disable automatic JBossMQ destination construction
> --------------------------------------------------
>
>                 Key: JBAS-2150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>             Fix For: No Release
>
>
> The automatic construction of JBossMQ destination construction is not portable
> and confuses most users when they configure things wrong.
> They don't get a reasonable error message, and sometimes no error message at all.
> This was made configurable in JBoss4 and should be disabled in JBoss5
> See conf/standardjboss.xml
> -        <CreateJBossMQDestination>true</CreateJBossMQDestination>
> +        <CreateJBossMQDestination>false</CreateJBossMQDestination>
> The testsuite will need fixing for any MDB deployments that were using this feature
> to have explicit destination deployments. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:38:34 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2150) Disable automatic
 JBossMQ destination construction
Message-ID: <29169316.1158323914705.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2150?page=all ]

Adrian Brock closed JBAS-2150.
------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                       (was: No Release)
       Resolution: Done
         Assignee: Adrian Brock

This was done a while ago in JBoss5.

> Disable automatic JBossMQ destination construction
> --------------------------------------------------
>
>                 Key: JBAS-2150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The automatic construction of JBossMQ destination construction is not portable
> and confuses most users when they configure things wrong.
> They don't get a reasonable error message, and sometimes no error message at all.
> This was made configurable in JBoss4 and should be disabled in JBoss5
> See conf/standardjboss.xml
> -        <CreateJBossMQDestination>true</CreateJBossMQDestination>
> +        <CreateJBossMQDestination>false</CreateJBossMQDestination>
> The testsuite will need fixing for any MDB deployments that were using this feature
> to have explicit destination deployments. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:38:34 2006
From: jira-events at jboss.com (Roland R?z (JIRA))
Date: Fri, 15 Sep 2006 08:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-706)
 NullPointerException in
 RunAsSecurityInterceptorFactory when there is no SecurityDomain annotation
Message-ID: <18518904.1158323914812.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException in RunAsSecurityInterceptorFactory when there is no SecurityDomain annotation
--------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-706
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-706
             Project: EJB 3.0
          Issue Type: Bug
          Components: Security
            Reporter: Roland R?z
            Priority: Minor


The class org.jboss.ejb3.security.RunAsSecurityInterceptorFactory throws in createPerClass() a NullPointerException when there is no SecurityDomain annotation.

Possible Fix:
if (securityAnnotation != null) {
  domain = ctx.lookup("java:/jaas/" + securityAnnotation.value());
}


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:35 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 15 Sep 2006 08:48:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2759919.1158324515796.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3597?page=all ]

Dimitris Andreadis updated JBAS-3597:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Unlikely to get done for 4.0.5

Started a thread in case those tests can be unified with JBM:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3971910#3971910

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2156) Patch to add expiry
 queue support to JBossMQ
Message-ID: <32179663.1158324516164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2156?page=all ]

Adrian Brock updated JBAS-2156:
-------------------------------

    Fix Version/s:     (was: No Release)

> Patch to add expiry queue support to JBossMQ
> --------------------------------------------
>
>                 Key: JBAS-2156
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2156
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Elias Ross
>         Assigned To: Elias Ross
>         Attachments: expiry.diff, expiry.diff, expiry.txt, ExpiryDestinationTestCase.java
>
>
> Added attributes "ExpiryDestination" to DestinationMBean and DestinationManagerMBean to indicate an ObjectName of queue to receive expired messages. This destination queue must be bound into JNDI when this queue starts.
> The messages are copied over to this queue when expiry time is reached and the original expiration and destination is kept in the vendor parameters "JBOSS_ORIG_EXPIRATION" and "JBOSS_ORIG_DESTINATION". The same JMSMessageID is kept in the copied message.
> The limitation of this is that the queue must be located on the same local JBoss server.
> Another limitation is that the expired message is only removed after its copy has been added to the new destination. Ideally, the "move" would happen within a single transaction.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2156) Patch to add expiry
 queue support to JBossMQ
Message-ID: <16531854.1158324516298.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2156?page=all ]

Adrian Brock updated JBAS-2156:
-------------------------------

    Comment: was deleted

> Patch to add expiry queue support to JBossMQ
> --------------------------------------------
>
>                 Key: JBAS-2156
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2156
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Elias Ross
>         Assigned To: Elias Ross
>         Attachments: expiry.diff, expiry.diff, expiry.txt, ExpiryDestinationTestCase.java
>
>
> Added attributes "ExpiryDestination" to DestinationMBean and DestinationManagerMBean to indicate an ObjectName of queue to receive expired messages. This destination queue must be bound into JNDI when this queue starts.
> The messages are copied over to this queue when expiry time is reached and the original expiration and destination is kept in the vendor parameters "JBOSS_ORIG_EXPIRATION" and "JBOSS_ORIG_DESTINATION". The same JMSMessageID is kept in the copied message.
> The limitation of this is that the queue must be located on the same local JBoss server.
> Another limitation is that the expired message is only removed after its copy has been added to the new destination. Ideally, the "move" would happen within a single transaction.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 08:48:36 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 08:48:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2156) Patch to add expiry
 queue support to JBossMQ
Message-ID: <22463417.1158324516409.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2156?page=all ]

Adrian Brock updated JBAS-2156:
-------------------------------

    Comment: was deleted

> Patch to add expiry queue support to JBossMQ
> --------------------------------------------
>
>                 Key: JBAS-2156
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2156
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Elias Ross
>         Assigned To: Elias Ross
>         Attachments: expiry.diff, expiry.diff, expiry.txt, ExpiryDestinationTestCase.java
>
>
> Added attributes "ExpiryDestination" to DestinationMBean and DestinationManagerMBean to indicate an ObjectName of queue to receive expired messages. This destination queue must be bound into JNDI when this queue starts.
> The messages are copied over to this queue when expiry time is reached and the original expiration and destination is kept in the vendor parameters "JBOSS_ORIG_EXPIRATION" and "JBOSS_ORIG_DESTINATION". The same JMSMessageID is kept in the copied message.
> The limitation of this is that the queue must be located on the same local JBoss server.
> Another limitation is that the expired message is only removed after its copy has been added to the new destination. Ideally, the "move" would happen within a single transaction.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:06:35 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 09:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-319) -props ./udp.xml
 finds udp.xml in classpath *before* file ./udp.xml
In-Reply-To: <25571427.1158298534007.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18326336.1158325595317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-319?page=all ]

Bela Ban resolved JGRP-319.
---------------------------

    Resolution: Done

> -props ./udp.xml finds udp.xml in classpath *before* file ./udp.xml
> -------------------------------------------------------------------
>
>                 Key: JGRP-319
>                 URL: http://jira.jboss.com/jira/browse/JGRP-319
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> If we explicitly define a relative path for a config file, then we must honor it, so find ./udp.xml *before* udp.xml in the classpath

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:08:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:08:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
In-Reply-To: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32004285.1158325723393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3620?page=all ]

Adrian Brock reassigned JBAS-3620:
----------------------------------

    Assignee: Adrian Brock

> JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBossMQ's PersistenceManager has a mechanism to retry recovery
> a number of times "RecoveryRetries".
> However, this only applies to the data recovery. If it fails 
> (e.g. due to database or network glitch)
> while checking/creating the database schema
> then no retries are done.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1908) listMessageCounter
 issue with JMS
 subscriptions containing certain message selector characters
Message-ID: <32367233.1158325843431.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1908?page=all ]

Adrian Brock updated JBAS-1908:
-------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> listMessageCounter issue with JMS subscriptions containing certain message selector characters
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-1908
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1908
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP Professional, JDK1.4.2_06, JBoss 4.0.2
>            Reporter: Jaco Joubert
>            Priority: Minor
>         Attachments: DestinationManager.txt, DestinationMBeanSupport.txt, listCounter.jar, MessageCounter.txt, test-topic-service.xml
>
>
> When the message selector query for a subscription to a JMS topic looks someting like "field in ('A', 'B', 'C')", two failures occur on JMS MBeans:
> 1.  The listMessageCounter operation on jboss.mq:service=DestinationManager fails with a NumberFormatException:
> Caused by: java.lang.NumberFormatException: For input string: " 'ghi'"
>   at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>   at java.lang.Integer.parseInt(Integer.java:468)
>   at java.lang.Integer.parseInt(Integer.java:518)
>   at org.jboss.mq.server.jmx.DestinationManager.listMessageCounter(DestinationManager.java:477)
>   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:324)
>   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>   ... 44 more
> This is because the getCounterAsString() method is used on the MessageCounter to get the details and then traversed with
> a StringTokenizer tokenizing on commas, but the subscription name also contains commas in this case.
> 2.  The listMessageCounter operation on jboss.mq.destination:name=[topicName],service=Topic works, but the resulting HTML
>     table has some of the selector values populating the counter columns.  The problem is because of the same issue as above.
>     
> This can be reproduced by following these steps:
> 1.  Startup a JBoss4.0.2 with default configuration.
> 2.  Deploy the attached 'test-topic-service.xml'.  This will create a JMS topic called 'counterTestTopic'.
> 3.  Run the attached client (source included in jar).  The only jar needed on classpath is the 'jbossall-client.jar':
>     java -cp "[path]\jbossall-client.jar;.\listCounter.jar" za.co.jdj.jbossmq.testcounter.TestListCounter
>     This will do the following:
>     3.1.  Connect to the JMS server running locally.
>     3.2.  Create a publisher and durable subscriber on the 'counterTestTopic' already deployed.
>           The subscriber has a message selector in the format already described
>     3.3.  Invoke the listMessageCounter operation on jboss.mq:service=DestinationManager, printing the error.
>     3.4.  Wait for the client to look at the html table created by the topic in a browser.
>     3.5.  Remove the subscription and exit.
>     
> Suggested fixes for the problem includes:
> 1.  Add a getDestinationTypeDescription() method to org.jboss.mq.server.MessageCounter.  (See MessageCounter.txt attached)
> 2.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationManager to not use the getCounterAsString() method
>     on org.jboss.mq.server.MessageCounter, but rather extract the values itself for the html table.
>     (See the DestinationManager.txt file attached).
> 3.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationMBeanSupport to do the same as above.
>     (See the DestinationMBeanSupport.txt file attached).

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1346) JDBC StateManager
Message-ID: <26174295.1158325843984.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1346?page=all ]

Adrian Brock updated JBAS-1346:
-------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> JDBC StateManager
> -----------------
>
>                 Key: JBAS-1346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1346
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> The JDBC StateManager should have operations to create/delete users and subscriptions in the
> database, just like the old File StateManager did.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3468) JMS Connection
 starts ping
 thread before ClientID is set resulting in the ClientMonitorInterceptor to
 close the connection after client timeout
In-Reply-To: <11361240.1154691131936.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20555830.1158325844214.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]

Adrian Brock reassigned JBAS-3468:
----------------------------------

    Assignee: Adrian Brock

> JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3468
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3468
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP
>            Reporter: Francis Labaere
>         Assigned To: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection  is set (explicitely using setClientID or implicitely).   The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
> The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap.  When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one.  When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken.  Subsequent calls to the server will generate exceptions: User session is not valid.
> On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
> Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive: 
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
> 2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.'  This exception is being propogated to the client as a HTTPILResponse.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade at 2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade at 1343c2a)
> On the Client side: following stacktrace is visible
> 13:17:57 [MessageListenerThread - MyTopic] WARN  org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> mq.Connection should start the ping thread after the ClientID is known.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3483) The javadoc
 relating to StdServerSessionPool pooling parameters is wrong
In-Reply-To: <33330695.1154959692644.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13734637.1158325844412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3483?page=all ]

Adrian Brock reassigned JBAS-3483:
----------------------------------

    Assignee: Weston Price

> The javadoc relating to StdServerSessionPool pooling parameters is wrong
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3483
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3483
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The javadoc in the StdServerSessionPool constructor is misleading.
> It refers to the pool parameters controlling the number of sessions when it
> primarily controls the number of threads. Only the MaxPoolSize controls the number of sessions
> which are created at pool construction time.
> This WIKI page has it correct:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMDB

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:10:44 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:10:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter
 makes unnecessary temporary delete requests
Message-ID: <22957957.1158325844670.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ]

Adrian Brock updated JBAS-1485:
-------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> JMS ResourceAdapter makes unnecessary temporary delete requests
> ---------------------------------------------------------------
>
>                 Key: JBAS-1485
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1485
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1
>            Reporter: Adrian Brock
>            Priority: Optional
>
> The JMS ResourceAdaptor keeps track of temporaries created on a connection
> (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl)
> and deletes them.
> This is because we cannot expect the real JMS implementation to do this
> because the connection is pooled and not closed.
> However, if the user is deleting the temporaries themselves
> (good practice in terms of resource usage),
> the JMS ResourceAdapter does not know about this
> and tries to repeat the delete at connection.close();
> Solution:
> Add some wrapping processing for the temporary queues and topics
> so we can trap temporary.delete(). That way we will know we don't
> need to do it on close()
> IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will
> also need to trap these destinations to do the necessary wrapping/unwrapping.
> It is also possible to retrieve a temporary destination with Session.createQueue/Topic.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:12:39 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:12:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26467656.1158325959828.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Adrian Brock updated JBAS-3628:
-------------------------------

    Component/s: JMS service

> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Fri Sep 15 09:14:43 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 15 Sep 2006 09:14:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7977366.1158326083620.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Adrian Brock reassigned JBAS-3628:
----------------------------------

    Assignee: Adrian Brock  (was: Luc Texier)

> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Fri Sep 15 09:42:36 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 15 Sep 2006 09:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3631) Missing branch in
 StdServerSession commit logic
In-Reply-To: <5722134.1157628523903.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20972896.1158327756438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3631?page=all ]

Weston Price resolved JBAS-3631.
--------------------------------

    Resolution: Done

Added transation branch to StdServerSession txn managment in onMessage. 

> Missing branch in StdServerSession commit logic
> -----------------------------------------------
>
>                 Key: JBAS-3631
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3631
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a missing branch in the StdServerSession commit logic.
> In the case where the transaction manager rollsback the transaction early,
> e.g. JBossTM does this for transaction timeouts, the status will be NO_TRANSACTION
> (or a heuristic state).
> The code:
>                // Marked rollback
>                if (trans.getStatus() == Status.STATUS_MARKED_ROLLBACK)
>                {
>                   if (trace)
>                      log.trace(StdServerSession.this + " rolling back JMS transaction tx=" + trans);
>                   // actually roll it back
>                   tm.rollback();
>                   // NO XASession? then manually rollback.
>                   // This is not so good but
>                   // it's the best we can do if we have no XASession.
>                   if (xaSession == null && serverSessionPool.isTransacted())
>                   {
>                      session.rollback();
>                   }
>                }
>                else if (trans.getStatus() == Status.STATUS_ACTIVE)
>                {
>                   // Commit tx
>                   // This will happen if
>                   // a) everything goes well
>                   // b) app. exception was thrown
>                   if (trace)
>                      log.trace(StdServerSession.this + " commiting the JMS transaction tx=" + trans);
>                   tm.commit();
>                   // NO XASession? then manually commit.  This is not so good but
>                   // it's the best we can do if we have no XASession.
>                   if (xaSession == null && serverSessionPool.isTransacted())
>                   {
>                      session.commit();
>                   }
>                }
> needs an extra branch:
>                else
>                {
>                   if (trace)
>                      log.trace(StdServerSession.this + " transaction already ended tx=" + trans);
>                   // spend the thread association
>                   tm.suspend();
>                   // NO XASession? then manually rollback.
>                   // This is not so good but
>                   // it's the best we can do if we have no XASession.
>                   if (xaSession == null && serverSessionPool.isTransacted())
>                   {
>                      session.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

        


From jira-events at jboss.com  Fri Sep 15 09:42:36 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 15 Sep 2006 09:42:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3483) The javadoc
 relating to StdServerSessionPool pooling parameters is wrong
In-Reply-To: <33330695.1154959692644.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3968004.1158327756688.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3483?page=all ]

Weston Price resolved JBAS-3483.
--------------------------------

    Resolution: Done

Updated JavaDoc to be more accurate for StdServerSessionPool parameters. 

> The javadoc relating to StdServerSessionPool pooling parameters is wrong
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3483
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3483
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The javadoc in the StdServerSessionPool constructor is misleading.
> It refers to the pool parameters controlling the number of sessions when it
> primarily controls the number of threads. Only the MaxPoolSize controls the number of sessions
> which are created at pool construction time.
> This WIKI page has it correct:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMDB

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 09:50:40 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 15 Sep 2006 09:50:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1040) Enhancements to
	DnD
Message-ID: <26504714.1158328240036.JavaMail.jira@cloud.prod.atl2.jboss.com>

Enhancements to DnD
-------------------

                 Key: JBPORTAL-1040
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1040
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


1. fix ordering to insert at the bottom-most area (after the last portlet).
2. dotted line cleanup.. 
    a. Either default to a simple insertion line, or
    b. try to simulate netvibes behaviour, of moving all below windows down and showing a highlighted target area.
3. cleanup messy and ill-performant code. (StringBuffers are your friend)
4. title bars, only, should be clickable for dragging.
5. Cursor should change to *something* when over a draggable region (before clicking).


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:12:37 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Fri, 15 Sep 2006 10:12:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-138) trailblazer demo has
 problems in some locales
Message-ID: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>

trailblazer demo has problems in some locales
---------------------------------------------

                 Key: JBESB-138
                 URL: http://jira.jboss.com/jira/browse/JBESB-138
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Examples
    Affects Versions: 4.0 Beta 1
            Reporter: Kurt Stam
         Assigned To: Kurt Stam
         Attachments: patch.txt

There a re parsing problems when converting a string (1000,00) to Double.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:12:37 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Fri, 15 Sep 2006 10:12:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-138) trailblazer demo has
 problems in some locales
In-Reply-To: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6626951.1158329557498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-138?page=all ]

Kurt Stam updated JBESB-138:
----------------------------

    Attachment: patch.txt

Patch to remove the cents in the formatting.

> trailblazer demo has problems in some locales
> ---------------------------------------------
>
>                 Key: JBESB-138
>                 URL: http://jira.jboss.com/jira/browse/JBESB-138
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Kurt Stam
>         Attachments: patch.txt
>
>
> There a re parsing problems when converting a string (1000,00) to Double.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:18:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 15 Sep 2006 10:18:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10209380.1158329927308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Fix Version/s: 1.4.0.SP2

Yep.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:36:36 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 15 Sep 2006 10:36:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
Message-ID: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>

Increase ClusterPartition buffers to support farming of large files
-------------------------------------------------------------------

                 Key: JBAS-3659
                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA


The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.

We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 10:57:39 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 10:57:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23865219.1158332259665.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-320?page=all ]

Bela Ban reassigned JGRP-320:
-----------------------------

    Assignee: Scott Marlow  (was: Bela Ban)

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Scott Marlow
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:26:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 15 Sep 2006 11:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-119) Parameter loading
 doesn't check for XML validity
In-Reply-To: <7780536.1154950212823.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11193414.1158334002660.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-119?page=all ]

Mark Little reassigned JBESB-119:
---------------------------------

    Assignee: David DeGroff  (was: Esteban Schifman)

> Parameter loading doesn't check for XML validity
> ------------------------------------------------
>
>                 Key: JBESB-119
>                 URL: http://jira.jboss.com/jira/browse/JBESB-119
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Critical
>             Fix For: 4.0
>
>
> The current ParamRepository approach has a File implementation. It all appears to work on Strings (with the comments indicating how the strings should be formatted for structured attributes). However, some user classes assume the String is XML. Parameters should be provided to application classes through name/value pairs. How those pairs are loaded into the system (XML, strings, file, etc.) should be hidden.
> We also need an ESB schema.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:26:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 15 Sep 2006 11:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-122) Schema needed
In-Reply-To: <17213696.1154955972421.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9607170.1158334002887.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-122?page=all ]

Mark Little reassigned JBESB-122:
---------------------------------

    Assignee: David DeGroff  (was: Esteban Schifman)

> Schema needed
> -------------
>
>                 Key: JBESB-122
>                 URL: http://jira.jboss.com/jira/browse/JBESB-122
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Critical
>             Fix For: 4.0
>
>
> XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:36:37 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Fri, 15 Sep 2006 11:36:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8016852.1158334597813.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343386 ] 
            
Max Andersen commented on JBIDE-354:
------------------------------------

damn - would be great if we soon could get mail notifications to work for these jira updates ;)

in any case, i like the new one mostly because it is more vibrant...the red color.

And looking at that i got the idea...

What about making the moon red(ish) instead ? (maybe also on the main logo ?)

So it won't be the sun that is "shining" but our red moon ?



> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:50:38 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:50:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14164997.1158335438646.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic updated JBREM-596:
----------------------------------

        Summary: Lease stops working if the First Client using the same Locator is closed  (was: Lease doesn't work if client has two connections opened when using callbacks)
    Description: 
If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)

Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.


Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

  was:
If you have two connections, one of them is using CallBack the Lease is just stopped.

I don't know how to reproduce this with a pure JBossRemoting testcase, but there is a testcase @ JBossMEssaging (Branch_1_0) which reproduces this really easily.

Download JBossMessaging SVN @ Branch_1, and execute ant crash-tests within /testsuite.

You can look at cruisecontrol results at this URL:

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest1(Crash).html

and

http://cruisecontrol.jboss.com/cc/artifacts/jms-1.0-testsuite/20060907220034/results/org/jboss/test/messaging/jms/crash/DurableCrashTest2(Crash).html


I have added a couple of messages on JBossRemoting code and I could see that with the code bellow, the lease is stopped. During addCallBAck the client copy calls disconnect and the lease thread never comes back.



Here is the code:


	   public void testSimplestDurableSubscription() throws Exception
	   {
	      ConnectionFactory cf = (ConnectionFactory)ic.lookup("ConnectionFactory");
	      Topic topic = (Topic)ic.lookup("/topic/TopicCrash");
	      
	      Connection conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();

	      Connection conn2 = cf.createConnection();
	      conn2.setClientID("client2");
	      conn2.start();

	      Session s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      Session s2 = conn2.createSession(true, Session.AUTO_ACKNOWLEDGE);

	      MessageProducer prod = s.createProducer(topic);
	      prod.setDeliveryMode(DeliveryMode.PERSISTENT);

	      MessageConsumer durable = s.createDurableSubscriber(topic, "subs1");
	      MessageConsumer durable2 = s2.createDurableSubscriber(topic, "subs2");

	      //conn2.close(); -- do not remote this comment. It was meant to not close the connection
	      
	      
	      for (int i=0;i<10;i++)
	      {
	    	  prod.send(s.createTextMessage("k"+i));
	      }
	      s.commit();

	      conn.close();
	      conn = cf.createConnection();
	      conn.setClientID("client1");
	      conn.start();
	      s = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);
	      durable = s.createDurableSubscriber(topic, "subs1");

	      for (int i=0;i<2;i++)
	      {
	    	  TextMessage tm = (TextMessage)durable.receive(1000);
	    	  assertNotNull(tm);
	    	  s.commit();
	    	  System.out.println(tm.getText());
	    	  assertEquals("k" + i, tm.getText());
	      }
	      
	      //conn.close();-- do not remote this comment. It was meant to not close the connection

	      //System.exit(0); -- this is not needed as there is not tearDown, the client VM will simply be finished the same way an exit would do, and this is better since it will keep proper JUNIT report outputs
	   }



> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:52:37 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:52:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31476201.1158335557170.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343388 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

I have updated org.jboss.test.remoting.lease.socket.multiple.SocketLeaseTestClient to have the appropriate testing scenario

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:52:37 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:52:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15809897.1158335557330.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343389 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

We would need this fix on a 2.0.1.GA (or having a snapsho we could use on JMS)

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:56:38 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Fri, 15 Sep 2006 11:56:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12184490.1158335798388.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Stan Silvert updated JBAS-3554:
-------------------------------

    Priority: Critical  (was: Major)

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 11:58:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 11:58:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24169465.1158335915571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Clebert Suconic updated JBMESSAGING-541:
----------------------------------------

    Assignee: Tom  Elrod  (was: Clebert Suconic)

Tom, this is a remoting but (the same one associated with this issue).


> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Fri Sep 15 12:00:35 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 12:00:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9029169.1158336035840.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic updated JBREM-596:
----------------------------------

    Comment: was deleted

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:00:36 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 12:00:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13521488.1158336036011.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343391 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

We would need this fix on a 2.0.1.GA (or having a snapshot we could use on Messaging)

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:34:36 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 15 Sep 2006 12:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1289887.1158338076513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Ryan Campbell reassigned JBAS-3650:
-----------------------------------

    Assignee: Prabhat Jha  (was: JBoss QA Lead)

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Prabhat Jha
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:34:36 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 15 Sep 2006 12:34:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28797539.1158338076664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Ryan Campbell updated JBAS-3650:
--------------------------------

    Due Date: 18/Sep/06

> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: Prabhat Jha
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 12:42:35 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 12:42:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-313) MultiplexerTests
 don't work with TCP configuration
In-Reply-To: <15805211.1158066153671.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29081274.1158338555209.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-313?page=all ]

Bela Ban resolved JGRP-313.
---------------------------

    Resolution: Done

> MultiplexerTests don't work with TCP configuration
> --------------------------------------------------
>
>                 Key: JGRP-313
>                 URL: http://jira.jboss.com/jira/browse/JGRP-313
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> UDP works 100%, however, some of the tests fail with a TCP configuration

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 13:00:36 2006
From: jira-events at jboss.com (Scott Marlow (JIRA))
Date: Fri, 15 Sep 2006 13:00:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27754779.1158339636995.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-320?page=comments#action_12343392 ] 
            
Scott Marlow commented on JGRP-320:
-----------------------------------

ConnectionTableNIO fix has been checked in.

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Scott Marlow
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 13:48:38 2006
From: jira-events at jboss.com (Jaroslaw Kijanowski (JIRA))
Date: Fri, 15 Sep 2006 13:48:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3660) Error starting up
 jaspi config on jboss-head testsuite module
Message-ID: <27348819.1158342518259.JavaMail.jira@cloud.prod.atl2.jboss.com>

Error starting up jaspi config on jboss-head testsuite module
-------------------------------------------------------------

                 Key: JBAS-3660
                 URL: http://jira.jboss.com/jira/browse/JBAS-3660
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Jaroslaw Kijanowski
         Assigned To: Anil Saldhana
             Fix For: JBossAS-5.0.0.Beta


The testsuite fails while starting the "jaspi" instance in jbossas beta 5:
tests.log:
***************************
tests-security-jaspi-unit:
     [echo] creating jaspi config
     [copy] Copying 153 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
     [echo] Overwriting config descriptors
     [copy] Copying 2 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
[server:start] Starting server "jaspi" with command: 
[server:start] /opt/jrockit-jdk1.5.0_06/bin/java -cp /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/bin/run.jar:/opt/jrockit-jdk1.5.0_06/lib/tools.jar  org.jboss.Main -c jaspi -b localhost 
BUILD FAILED
/services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:827: The following error occurred while executing this line:
/services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:2414: Error starting server "jaspi": Server failed to start; see logs.
**************************
The server.log contains this:
**************************
11:25:01,556 ERROR [AbstractKernelController] Error installing to Configured: name=jboss.web:service=WebServer state=Instantiated mode=Manual requiredState=Configured
org.jboss.deployment.DeploymentException: No Attribute found with name: AuthorizationManagerService for jboss.web:service=WebServer
        at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java: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

        


From jira-events at jboss.com  Fri Sep 15 14:06:37 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Fri, 15 Sep 2006 14:06:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-300) move()
Message-ID: <24373359.1158343597332.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-300?page=all ]

Manik Surtani closed JBCACHE-300.
---------------------------------

    Resolution: Done

> move()
> ------
>
>                 Key: JBCACHE-300
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-300
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Bela Ban
>         Assigned To: Manik Surtani
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Moves an entire subtree under a different subtree

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 14:06:37 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Fri, 15 Sep 2006 14:06:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-254) Provide an
 efficient way to relocate a child Node
Message-ID: <24588010.1158343597467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-254?page=all ]

Manik Surtani closed JBCACHE-254.
---------------------------------

    Fix Version/s: 2.0.0
                       (was: 2.1.0)
       Resolution: Done

Fixed this in 2.0.0 - a single move() impl.

> Provide an efficient way to relocate a child Node
> -------------------------------------------------
>
>                 Key: JBCACHE-254
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-254
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0
>
>
> Can TreeCache provide an efficient to re-locate a child Node say from parent A to parent B? The only problem I see is the associated fqn name. I may need this feature in TreeCacheAop.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 14:34:43 2006
From: jira-events at jboss.com (James Cobb (JIRA))
Date: Fri, 15 Sep 2006 14:34:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-354) 16x16 and 32x32
 icon for JBossIDE
In-Reply-To: <4705171.1156806139396.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12389352.1158345283682.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-354?page=comments#action_12343394 ] 
            
James Cobb commented on JBIDE-354:
----------------------------------

I made a third version that replaced the black moon with a red one as per Max's feedback. The sun is still shining, but the moon blocks the view, hence the rays around it. :)


http://65.244.175.215:8080/files/design/jbossIDE_2.0/index.htm


16 x 16
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_16_jbosside_v3.gif

32 x 32
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_32_jbosside_v3.gif

They can be seen in action here:
http://65.244.175.215:8080/files/design/jbossIDE_2.0/images/ico_jbosside_page_v3.gif

> 16x16 and 32x32 icon for JBossIDE
> ---------------------------------
>
>                 Key: JBIDE-354
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-354
>             Project: JBoss IDE
>          Issue Type: Feature Request
>            Reporter: Marshall Culpepper
>         Assigned To: James Cobb
>
> We need a smaller 16x16 and 32x32 icon representation of our beautiful new logo =)

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 14:36:34 2006
From: jira-events at jboss.com (Adam Brod (JIRA))
Date: Fri, 15 Sep 2006 14:36:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-354) Better support for
 JSF-style managed properties
Message-ID: <28874974.1158345394933.JavaMail.jira@cloud.prod.atl2.jboss.com>

Better support for JSF-style managed properties
-----------------------------------------------

                 Key: JBSEAM-354
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-354
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: JSF
    Affects Versions: 1.0.1
            Reporter: Adam Brod
            Priority: Minor


The @In annotation should support the same syntax as JSF managed properties.  That means that If I have this annotation in my Bean:

@In("#{param.fileId}")
Long fileId

Seam should automatically inject that property performing the correct JSF conversion.  In Shale I can do that with the @Value or @Property annotation.  It is very confusing that I need a specialized annotation that doesn't support the EL just for request parameters when JSF doesn't make that distinction.

I believe this could be implemented with a few small changes to Component.  Inside Component.getInstanceToInject(...), the logic which first checks to see if the name is an EL (line 1358 in Seam 1.0.1) could also check to see if the expression begins with "#{param.", if so, then it can call to Component.convertRequestParameter(...) to convert the type.

This is a small change to Component, but it makes the overall Seam API more consistent.  It allows me to use the EL anywhere I want.  I don't have to worry about using @In or @RequestParameter, I just use the EL.



-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:04:37 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:04:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3661) LdapExtLoginModule
 should detect communication failures midstream
Message-ID: <21180085.1158350677198.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule should detect communication failures midstream
-----------------------------------------------------------------

                 Key: JBAS-3661
                 URL: http://jira.jboss.com/jira/browse/JBAS-3661
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Scott M Stark


There is a possibility of the context going stale due to communication exceptions with the ldap server when dealing with references etc.  It may be useful for the LdapExtLoginModule to implement the:
http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/UnsolicitedNotificationListener.html

such that it can do graceful processing.


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:06:35 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-5) Integrate OpenDS in
 HEAD testsuite
In-Reply-To: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17565281.1158350795839.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-5?page=all ]

Anil Saldhana closed SECURITY-5.
--------------------------------

    Fix Version/s: 2.0
       Resolution: Done

asaldhana~/jboss-5.0/jboss-head/testsuite>ant tests-ldap
Buildfile: build.xml
Overriding previous definition of reference to jboss.test.classpath

tests-ldap:
     [echo] creating opends config
     [echo] Overwriting config descriptors
     [copy] Copying 20 files to C:\cygwin\home\asaldhana\jboss-5.0\jboss-head\bu
ild\output\jboss-5.0.0.Beta\server\opends
[server:start] Starting server "opends" with command:
[server:start] C:\Java\jdk1.5.0_04\bin\java -cp C:\cygwin\home\asaldhana\jboss-5
.0\jboss-head\build\output\jboss-5.0.0.Beta\bin\run.jar;c:\java\jdk1.5.0_04\lib\
tools.jar   org.jboss.Main -c opends -b localhost
     [echo] Starting patternset=ldap.includes config=opends
    [junit] Running org.jboss.test.security.test.opends.LdapBasicUnitTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.922 sec
[server:stop] Shutting down server: opends

BUILD SUCCESSFUL
Total time: 31 seconds

> Integrate OpenDS in HEAD testsuite
> ----------------------------------
>
>                 Key: SECURITY-5
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule
> Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.
> My prelim testing details:
> ====================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
> [12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
>  Directory Server 0.1-build007 starting up."
> [12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
> database backend containing 1 entries has started."
> [12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
> msg="Access control has been disabled."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
> rectory Server has started successfully."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
> rectory Server has sent an alert notification generated by class org.opends.serv
> er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
> ert ID 458887):  The Directory Server has started successfully.."
> ================================================================================
> =============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
> -D "cn=Directory Manager" -w password -a -f a.ldif
> Processing ADD request for dc=jboss,dc=org.
> ADD operation successful for DN dc=jboss,dc=org.
> Processing ADD request for ou=People,dc=jboss,dc=org.
> ADD operation successful for DN ou=People,dc=jboss,dc=org.
> Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.
> ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.
> Processing ADD request for ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ===============================================================================
> ==============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
>  -b "dc=jboss,dc=org" -s sub "objectclass=*"
> dn: dc=jboss,dc=org
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o: JBoss
> dc: jboss
> dn: ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: person
> objectClass: uidObject
> userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
> cn: Java Duke
> sn: Duke
> uid: jduke
> =====================================================================================
> The application policy:
> <application-policy name = "jmx-console">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
>                           flag="required">
>                 <module-option name="java.naming.factory.initial"> 
>                     com.sun.jndi.ldap.LdapCtxFactory
>                     </module-option>
>                 <module-option name="java.naming.provider.url">
>                     ldap://localhost:389/
>                 </module-option>
>                 <module-option name="java.naming.security.authentication">
>                     simple
>                 </module-option>
>                 <module-option name="principalDNPrefix">uid=</module-option>                    
>                 <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
>                 <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
>                 <module-option name="uidAttributeID">member</module-option>
>                 <module-option name="matchOnUserDN">true</module-option>
>                 <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false</module-option>
>                 <module-option name="searchTimeLimit">5000</module-option>
>                 <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
>             </login-module>
>         </authentication>
>     </application-policy>

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:06:35 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:06:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-8) LdapExtLoginModule
 should detect communication failures midstream
Message-ID: <1391642.1158350795955.JavaMail.jira@cloud.prod.atl2.jboss.com>

 LdapExtLoginModule should detect communication failures midstream
------------------------------------------------------------------

                 Key: SECURITY-8
                 URL: http://jira.jboss.com/jira/browse/SECURITY-8
             Project: JBoss Security
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0


http://jira.jboss.com/jira/browse/JBAS-3661

There is a possibility of the context going stale due to communication exceptions with the ldap server when dealing with references etc. It may be useful for the LdapExtLoginModule to implement the:
http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/UnsolicitedNotificationListener.html

such that it can do graceful processing. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:06:36 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 16:06:36 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3661) LdapExtLoginModule
 should detect communication failures midstream
In-Reply-To: <21180085.1158350677198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27531794.1158350796109.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3661?page=all ]

Anil Saldhana updated JBAS-3661:
--------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> LdapExtLoginModule should detect communication failures midstream
> -----------------------------------------------------------------
>
>                 Key: JBAS-3661
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3661
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.6.CR1
>
>
> There is a possibility of the context going stale due to communication exceptions with the ldap server when dealing with references etc.  It may be useful for the LdapExtLoginModule to implement the:
> http://java.sun.com/j2se/1.3/docs/api/javax/naming/ldap/UnsolicitedNotificationListener.html
> such that it can do graceful processing.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:08:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 16:08:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-320)
 ConnectionTable/ConnectionTableNIO have leftover threads after stop()
In-Reply-To: <633410.1158322113798.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7927084.1158350917175.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-320?page=all ]

Bela Ban resolved JGRP-320.
---------------------------

    Resolution: Done

Scott changed ConnectionTableNIO, now those tests work too

> ConnectionTable/ConnectionTableNIO have leftover threads after stop()
> ---------------------------------------------------------------------
>
>                 Key: JGRP-320
>                 URL: http://jira.jboss.com/jira/browse/JGRP-320
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Scott Marlow
>             Fix For: 2.4
>
>
> Unit test ConnectionTableTest shows this, use the following system properties:
> -Dbind.address=127.0.0.1 -Djgroups.tcpping.initial_hosts=127.0.0.1[7800]

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 16:08:37 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 15 Sep 2006 16:08:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-321)
 CloseTest.testShutdown() fails with -Dconfig=tcp.xml
Message-ID: <20644013.1158350917305.JavaMail.jira@cloud.prod.atl2.jboss.com>

CloseTest.testShutdown() fails with -Dconfig=tcp.xml
----------------------------------------------------

                 Key: JGRP-321
                 URL: http://jira.jboss.com/jira/browse/JGRP-321
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4




-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:02:35 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Fri, 15 Sep 2006 17:02:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBIDE-367) Eclipse dependancy
 versions are too strict/narrow
Message-ID: <5909308.1158354155429.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eclipse dependancy versions are too strict/narrow
-------------------------------------------------

                 Key: JBIDE-367
                 URL: http://jira.jboss.com/jira/browse/JBIDE-367
             Project: JBoss IDE
          Issue Type: Bug
          Components: Build System (Releng)
    Affects Versions: 2.0.0.Beta1
            Reporter: Darryl Miles
         Assigned To: Marshall Culpepper
            Priority: Minor


Release versioning is too strict and does not allow compatible newer versions of WTP/EMFXSD to be installed.


Related URLs:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87879&postdays=0&postorder=asc&start=10
http://opensource.atlassian.com/projects/hibernate/browse/HBX-709


This is the error list for after I upgraded WTP to the current I-build for this week.  Note I have all of these features/plugins installed but slightly newer versions of them the problem is the features.xml for the JbossIDE product is too strict insisting in the exact version it was built with.  When it should really make that the oldest version it will accept.

Plug-in "org.eclipse.wst.xml.core" version "1.1.0.v200606142000" referenced by this feature is missing.
Plug-in "org.eclipse.wst.xml.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.sse.core" version "1.1.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.sse.ui" version "1.0.101.v200606191900" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.uriresolver" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.validation" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.frameworks" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.ui" version "1.1.0.v200606142122" referenced by this feature is missing.
Plug-in "org.eclipse.emf.ecore" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.emf.ecore.xmi" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.jst.jsp.core" version "1.1.0.v200606191945" referenced by this feature is missing.
Plug-in "org.eclipse.jst.jsp.ui" version "1.1.0.v200606191945" referenced by this feature is missing.
Plug-in "org.eclipse.wst.html.core" version "1.1.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.html.standard.dtds" version "1.0.0" referenced by this feature is missing.
Plug-in "org.eclipse.wst.html.ui" version "1.0.100.v200606191945" referenced by this feature is missing.
Plug-in "org.eclipse.wst.css.core" version "1.1.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.css.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.javascript.core" version "1.0.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.javascript.ui" version "1.0.0.v200606141450" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.environment" version "1.0.100.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.emf.common" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.emf" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.emfworkbench.integration" version "1.1.0.v200606130645" referenced by this feature is missing.
Plug-in "org.eclipse.emf.edit" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.xsd" version "2.2.0.v200606271057" referenced by this feature is missing.
Plug-in "org.eclipse.wst.common.project.facet.core" version "1.1.0.v200606130645" referenced by this feature is missing.


-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:18:33 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 17:18:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-5) Integrate OpenDS
 in HEAD testsuite
In-Reply-To: <19541215.1158089195639.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31950215.1158355113618.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/SECURITY-5?page=comments#action_12343398 ] 
            
Anil Saldhana commented on SECURITY-5:
--------------------------------------

There is a XMBean service that starts/stops OpenDS inside a JBoss instance.
org.jboss.test.security.test.opends.OpenDSService


Also, there is a server configuration called as "opends" that sets up the opends config structure under:
jboss_instance/server/opends/conf/opends


Some DS log files are found under jboss_instance/server/opends/conf/opends/logs (access,errors,debug)

Also take notice of a OpenDS utility class in the test suite that can be used to add ldifs, delete DN, search etc.
org.jboss.test.security.test.opends.OpenDSUtil

> Integrate OpenDS in HEAD testsuite
> ----------------------------------
>
>                 Key: SECURITY-5
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-5
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> My preliminary testing with OpenDS has been a success. I was able to secure a jmx-console using the LdapLoginModule with the example1.ldif in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=LdapExtLoginModule
> Since the configuration of OpenDS is based on scripts that internally call java classes, it should be easy to integrate it into HEAD testsuite.
> My prelim testing details:
> ====================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>start-ds
> [12/Sep/2006:12:57:14 -0500] category=CORE severity=NOTICE id=458886 msg="OpenDS
>  Directory Server 0.1-build007 starting up."
> [12/Sep/2006:12:57:15 -0500] category=BACKEND severity=NOTICE id=8847402 msg="A
> database backend containing 1 entries has started."
> [12/Sep/2006:12:57:16 -0500] category=CONFIG severity=SEVERE_WARNING id=3277325
> msg="Access control has been disabled."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458887 msg="The Di
> rectory Server has started successfully."
> [12/Sep/2006:12:57:17 -0500] category=CORE severity=NOTICE id=458891 msg="The Di
> rectory Server has sent an alert notification generated by class org.opends.serv
> er.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, al
> ert ID 458887):  The Directory Server has started successfully.."
> ================================================================================
> =============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapmodify -h localhost
> -D "cn=Directory Manager" -w password -a -f a.ldif
> Processing ADD request for dc=jboss,dc=org.
> ADD operation successful for DN dc=jboss,dc=org.
> Processing ADD request for ou=People,dc=jboss,dc=org.
> ADD operation successful for DN ou=People,dc=jboss,dc=org.
> Processing ADD request for uid=jduke,ou=People,dc=jboss,dc=org.
> ADD operation successful for DN uid=jduke,ou=People,dc=jboss,dc=org.
> Processing ADD request for ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=Echo,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=Echo,ou=Roles,dc=jboss,dc=org.
> Processing ADD request for cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ADD operation successful for DN cn=TheDuke,ou=Roles,dc=jboss,dc=org.
> ===============================================================================
> ==============================================================================
> C:\cygwin\home\asaldhana\opends\OpenDS-0.1-build007\bin>ldapsearch -h localhost
>  -b "dc=jboss,dc=org" -s sub "objectclass=*"
> dn: dc=jboss,dc=org
> objectClass: top
> objectClass: dcObject
> objectClass: organization
> o: JBoss
> dc: jboss
> dn: ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: organizationalUnit
> ou: People
> dn: uid=jduke,ou=People,dc=jboss,dc=org
> objectClass: top
> objectClass: person
> objectClass: uidObject
> userPassword: {SSHA}XM3FqJX2rfY5Cnzd1Q77gBIsSaiS/MWFfg2LPw==
> cn: Java Duke
> sn: Duke
> uid: jduke
> =====================================================================================
> The application policy:
> <application-policy name = "jmx-console">
>         <authentication>
>             <login-module code="org.jboss.security.auth.spi.LdapLoginModule"
>                           flag="required">
>                 <module-option name="java.naming.factory.initial"> 
>                     com.sun.jndi.ldap.LdapCtxFactory
>                     </module-option>
>                 <module-option name="java.naming.provider.url">
>                     ldap://localhost:389/
>                 </module-option>
>                 <module-option name="java.naming.security.authentication">
>                     simple
>                 </module-option>
>                 <module-option name="principalDNPrefix">uid=</module-option>                    
>                 <module-option name="principalDNSuffix">,ou=People,dc=jboss,dc=org</module-option>
>                 <module-option name="rolesCtxDN">ou=Roles,dc=jboss,dc=org</module-option>
>                 <module-option name="uidAttributeID">member</module-option>
>                 <module-option name="matchOnUserDN">true</module-option>
>                 <module-option name="roleAttributeID">cn</module-option>
>                 <module-option name="roleAttributeIsDN">false</module-option>
>                 <module-option name="searchTimeLimit">5000</module-option>
>                 <module-option name="searchScope">ONELEVEL_SCOPE</module-option>
>             </login-module>
>         </authentication>
>     </application-policy>

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:30:37 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:30:37 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-408) Queue binds in
 jndi but cannot be looked up
Message-ID: <7618458.1158355837466.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=all ]

Clebert Suconic updated JBMESSAGING-408:
----------------------------------------

    Attachment: test.tar.gz

> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:38:34 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Fri, 15 Sep 2006 17:38:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16809247.1158356314781.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=all ]

Boleslaw Dawidowicz updated JBPORTAL-1034:
------------------------------------------

    Description: 
- define architecture, goals and roadmap for portal - ldap integration
- prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration


  was:prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration


> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>          Time Spent: 1 week, 2 hours
>
> - define architecture, goals and roadmap for portal - ldap integration
> - prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:40:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBMESSAGING-408) Queue binds
 in jndi but cannot be looked up
Message-ID: <32966760.1158356434258.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=all ]

Clebert Suconic resolved JBMESSAGING-408.
-----------------------------------------

    Fix Version/s:     (was: 1.0.1.CR5)
       Resolution: Cannot Reproduce Bug

I suspect you have a configuration issue with your security system.


I have deployed your application, and never had any exceptions. (I had to place jboss-messaging.jar into /lib though).

> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:40:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-408) Queue binds in
 jndi but cannot be looked up
Message-ID: <4499909.1158356434445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=all ]

Clebert Suconic closed JBMESSAGING-408.
---------------------------------------


> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 17:40:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 17:40:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-408) Queue binds
 in jndi but cannot be looked up
Message-ID: <20203991.1158356434612.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-408?page=comments#action_12343401 ] 
            
Clebert Suconic commented on JBMESSAGING-408:
---------------------------------------------

You will find test.tar.gz with my package (which has a small build.xml) and few changes I have made.

> Queue binds in jndi but cannot be looked up
> -------------------------------------------
>
>                 Key: JBMESSAGING-408
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-408
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>         Environment: Windows XP, JBoss 4.0.4GA with EJB3
>            Reporter: Paul Smith
>         Assigned To: Clebert Suconic
>         Attachments: JBoss_queue_binding_issue.zip, test.tar.gz
>
>
> The issue is described under the following forum entry:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=82842
> In short the queue is bound in jndi but cannot be looked up from the context. I have traced what messaging I can but can find no errors. I have also attached the relevant configuration xml and test EJB3 session bean. The connection factory can be looked up correctly but the queue cannot for some reason.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 18:26:34 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 15 Sep 2006 18:26:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <24986188.1158359194768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Clebert Suconic updated JBMESSAGING-432:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90803

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 19:14:39 2006
From: jira-events at jboss.com (Max Andersen (JIRA))
Date: Fri, 15 Sep 2006 19:14:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-367) Eclipse dependancy
 versions are too strict/narrow
In-Reply-To: <5909308.1158354155429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23425467.1158362079045.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-367?page=comments#action_12343408 ] 
            
Max Andersen commented on JBIDE-367:
------------------------------------

is this against the nightly build or the release ?



> Eclipse dependancy versions are too strict/narrow
> -------------------------------------------------
>
>                 Key: JBIDE-367
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-367
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Build System (Releng)
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Marshall Culpepper
>            Priority: Minor
>
> Release versioning is too strict and does not allow compatible newer versions of WTP/EMFXSD to be installed.
> Related URLs:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87879&postdays=0&postorder=asc&start=10
> http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> This is the error list for after I upgraded WTP to the current I-build for this week.  Note I have all of these features/plugins installed but slightly newer versions of them the problem is the features.xml for the JbossIDE product is too strict insisting in the exact version it was built with.  When it should really make that the oldest version it will accept.
> Plug-in "org.eclipse.wst.xml.core" version "1.1.0.v200606142000" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.xml.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.ui" version "1.0.101.v200606191900" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.uriresolver" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.validation" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.frameworks" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.ui" version "1.1.0.v200606142122" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore.xmi" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.core" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.ui" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.standard.dtds" version "1.0.0" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.ui" version "1.0.100.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.core" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.ui" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.environment" version "1.0.100.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.common" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emf" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emfworkbench.integration" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.edit" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.xsd" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.project.facet.core" version "1.1.0.v200606130645" referenced by this feature is missing.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 19:26:34 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 15 Sep 2006 19:26:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1041) WSRP's
 processing of fragments leaves the fragment in incoherent state
Message-ID: <22480412.1158362794036.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP's processing of fragments leaves the fragment in incoherent state
----------------------------------------------------------------------

                 Key: JBPORTAL-1041
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1041
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1


We currently only add rewriting tokens for id attributes. However, doing so, we fail to also add the tokens when the id are used (in javascript, for example).

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 20:58:33 2006
From: jira-events at jboss.com (Darryl Miles (JIRA))
Date: Fri, 15 Sep 2006 20:58:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBIDE-367) Eclipse dependancy
 versions are too strict/narrow
In-Reply-To: <5909308.1158354155429.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5007313.1158368313361.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBIDE-367?page=comments#action_12343410 ] 
            
Darryl Miles commented on JBIDE-367:
------------------------------------

The Release, but I've got the Nightly built so I'll give that a go tomorrow.

> Eclipse dependancy versions are too strict/narrow
> -------------------------------------------------
>
>                 Key: JBIDE-367
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-367
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: Build System (Releng)
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Marshall Culpepper
>            Priority: Minor
>
> Release versioning is too strict and does not allow compatible newer versions of WTP/EMFXSD to be installed.
> Related URLs:
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=87879&postdays=0&postorder=asc&start=10
> http://opensource.atlassian.com/projects/hibernate/browse/HBX-709
> This is the error list for after I upgraded WTP to the current I-build for this week.  Note I have all of these features/plugins installed but slightly newer versions of them the problem is the features.xml for the JbossIDE product is too strict insisting in the exact version it was built with.  When it should really make that the oldest version it will accept.
> Plug-in "org.eclipse.wst.xml.core" version "1.1.0.v200606142000" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.xml.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.sse.ui" version "1.0.101.v200606191900" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.uriresolver" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.validation" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.frameworks" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.ui" version "1.1.0.v200606142122" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.ecore.xmi" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.core" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.jst.jsp.ui" version "1.1.0.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.standard.dtds" version "1.0.0" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.html.ui" version "1.0.100.v200606191945" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.core" version "1.1.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.css.ui" version "1.0.100.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.core" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.javascript.ui" version "1.0.0.v200606141450" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.environment" version "1.0.100.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.common" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emf" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.emfworkbench.integration" version "1.1.0.v200606130645" referenced by this feature is missing.
> Plug-in "org.eclipse.emf.edit" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.xsd" version "2.2.0.v200606271057" referenced by this feature is missing.
> Plug-in "org.eclipse.wst.common.project.facet.core" version "1.1.0.v200606130645" referenced by this feature is missing.

-- 
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

        


From jira-events at jboss.com  Fri Sep 15 21:34:33 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 21:34:33 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3660) Error starting up
 jaspi config on jboss-head testsuite module
In-Reply-To: <27348819.1158342518259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7754828.1158370473957.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3660?page=all ]

Anil Saldhana closed JBAS-3660.
-------------------------------

    Resolution: Done

> Error starting up jaspi config on jboss-head testsuite module
> -------------------------------------------------------------
>
>                 Key: JBAS-3660
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3660
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Jaroslaw Kijanowski
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The testsuite fails while starting the "jaspi" instance in jbossas beta 5:
> tests.log:
> ***************************
> tests-security-jaspi-unit:
>      [echo] creating jaspi config
>      [copy] Copying 153 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
>      [echo] Overwriting config descriptors
>      [copy] Copying 2 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
> [server:start] Starting server "jaspi" with command: 
> [server:start] /opt/jrockit-jdk1.5.0_06/bin/java -cp /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/bin/run.jar:/opt/jrockit-jdk1.5.0_06/lib/tools.jar  org.jboss.Main -c jaspi -b localhost 
> BUILD FAILED
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:827: The following error occurred while executing this line:
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:2414: Error starting server "jaspi": Server failed to start; see logs.
> **************************
> The server.log contains this:
> **************************
> 11:25:01,556 ERROR [AbstractKernelController] Error installing to Configured: name=jboss.web:service=WebServer state=Instantiated mode=Manual requiredState=Configured
> org.jboss.deployment.DeploymentException: No Attribute found with name: AuthorizationManagerService for jboss.web:service=WebServer
>         at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java: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

        


From jira-events at jboss.com  Fri Sep 15 21:34:34 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 15 Sep 2006 21:34:34 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3660) Error starting up
 jaspi config on jboss-head testsuite module
In-Reply-To: <27348819.1158342518259.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30047668.1158370474136.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3660?page=comments#action_12343411 ] 
            
Anil Saldhana commented on JBAS-3660:
-------------------------------------

Should be fixed now.

> Error starting up jaspi config on jboss-head testsuite module
> -------------------------------------------------------------
>
>                 Key: JBAS-3660
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3660
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Jaroslaw Kijanowski
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The testsuite fails while starting the "jaspi" instance in jbossas beta 5:
> tests.log:
> ***************************
> tests-security-jaspi-unit:
>      [echo] creating jaspi config
>      [copy] Copying 153 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
>      [echo] Overwriting config descriptors
>      [copy] Copying 2 files to /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/server/jaspi
> [server:start] Starting server "jaspi" with command: 
> [server:start] /opt/jrockit-jdk1.5.0_06/bin/java -cp /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/build/output/jboss-5.0.0.Beta/bin/run.jar:/opt/jrockit-jdk1.5.0_06/lib/tools.jar  org.jboss.Main -c jaspi -b localhost 
> BUILD FAILED
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:827: The following error occurred while executing this line:
> /services/cruisecontrol/checkout/jboss-head-testsuite-1.5/testsuite/build.xml:2414: Error starting server "jaspi": Server failed to start; see logs.
> **************************
> The server.log contains this:
> **************************
> 11:25:01,556 ERROR [AbstractKernelController] Error installing to Configured: name=jboss.web:service=WebServer state=Instantiated mode=Manual requiredState=Configured
> org.jboss.deployment.DeploymentException: No Attribute found with name: AuthorizationManagerService for jboss.web:service=WebServer
>         at org.jboss.system.ServiceConfigurator.configure(ServiceConfigurator.java: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

        


From jira-events at jboss.com  Sat Sep 16 01:20:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 01:20:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-770) PojoCache to
 support non-serializable and no-aspectized POJO
Message-ID: <13802366.1158384047408.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to support non-serializable and no-aspectized POJO
------------------------------------------------------------

                 Key: JBCACHE-770
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-770
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: PojoCache


Currently in 2.0, we have to drop the support for the non-serializable and non-aspectized POJO, that is, a POJO that is neither implements Serializable or instrumented.



-- 
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

        


From jira-events at jboss.com  Sat Sep 16 01:32:47 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 16 Sep 2006 01:32:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1040) Enhancements
	to DnD
In-Reply-To: <26504714.1158328240036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16545980.1158384767381.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1040?page=comments#action_12343412 ] 
            
Roy Russo commented on JBPORTAL-1040:
-------------------------------------

1-3, complete. 

4 & 5 are related. Suggested fix is, when an emptyrenderer window is encountered make entire area draggable. For other renderers, use title bar.

> Enhancements to DnD
> -------------------
>
>                 Key: JBPORTAL-1040
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1040
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> 1. fix ordering to insert at the bottom-most area (after the last portlet).
> 2. dotted line cleanup.. 
>     a. Either default to a simple insertion line, or
>     b. try to simulate netvibes behaviour, of moving all below windows down and showing a highlighted target area.
> 3. cleanup messy and ill-performant code. (StringBuffers are your friend)
> 4. title bars, only, should be clickable for dragging.
> 5. Cursor should change to *something* when over a draggable region (before clicking).

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 07:54:47 2006
From: jira-events at jboss.com (Steven Williams (JIRA))
Date: Sat, 16 Sep 2006 07:54:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-483) Open Decision
 Table API to allow custom RuleSheetListeners
In-Reply-To: <21379798.1157959843818.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3470210.1158407687595.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-483?page=all ]

Steven Williams resolved JBRULES-483.
-------------------------------------

    Fix Version/s: 3.0.5
       Resolution: Done

Opened up API and added example custom listener.

> Open Decision Table API to allow custom RuleSheetListeners
> ----------------------------------------------------------
>
>                 Key: JBRULES-483
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-483
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Steven Williams
>         Assigned To: Mark Proctor
>             Fix For: 3.0.5
>
>         Attachments: Rule.java, RuleSheetListener.java, SpreadsheetCompiler.java
>
>
> I have a need for a different format for my decision tables - basically instead of the current format with one row per rule with conditions across the top I need to support a matrix-like structure where both the horizontal and the vertical axes represent conditions and the intersection represents the action. In order to do this I created my own MatrixRuleSheetListener inheriting from RuleSheetListener and overriding certain methods. This all works fine however I had to hack the drools code a little to allow me to do it. I was wondering if it would be possible to open up the API to allow this.
> Specifically:
> 1. add method to org.drools.decisiontable.parser.RuleSheetListener
>     protected void addRule(Rule rule)
>     {
>         this._ruleList.add(rule);
>     }
> 2. add empty protected methods preInitRuleTable(row, column, value) and postInitRuleTable(row, column, value, rule) to org.drools.decisiontable.parser.RuleSheetListener which are called from the start and end of the initRuleTable method.
> 3. Add agendaGroup property to org.drools.decisiontable.model.Rule
> 4. Add a new method compile(InputStream, InputType, RuleSheetListener) to org.drools.decisiontable.SpreadsheetCompiler
> I have attached these changes to this request.
> Steve

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 11:12:47 2006
From: jira-events at jboss.com (=?UTF-8?Q?Ortwin_Gl=C3=BCck_=28JIRA=29?=)
Date: Sat, 16 Sep 2006 11:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (HIBERNATE-46) Javassist lazy
 proxy factoring not thread-safe
Message-ID: <18818166.1158419567580.JavaMail.jira@cloud.prod.atl2.jboss.com>

Javassist lazy proxy factoring not thread-safe
----------------------------------------------

                 Key: HIBERNATE-46
                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-46
             Project: Hibernate
          Issue Type: Bug
         Environment: JBoss AS 4.0.4 with EJB 3-RC8
            Reporter: Ortwin Gl?ck
         Assigned To: Steve Ebersole


Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.

The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.

Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
s definition: test/BusinessOrganization_$$_javass
ist_272
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
        at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
JavassistLazyInitializer.java:79)
        ... 136 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
e class definition: ch/logobject/mlogistics/om/resource/BusinessOrganization_$$_
javassist_272
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
        ... 137 more
Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
        at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
        ... 138 more

-- 
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

       



From jira-events at jboss.com  Sat Sep 16 11:14:47 2006
From: jira-events at jboss.com (=?UTF-8?Q?Ortwin_Gl=C3=BCck_=28JIRA=29?=)
Date: Sat, 16 Sep 2006 11:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (HIBERNATE-46) Javassist lazy
 proxy factoring not thread-safe
In-Reply-To: <18818166.1158419567580.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22042126.1158419687477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/HIBERNATE-46?page=all ]

Ortwin Gl?ck updated HIBERNATE-46:
----------------------------------

    Description: 
Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.

The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.

Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
s definition: test/BusinessOrganization_$$_javass
ist_272
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
        at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
JavassistLazyInitializer.java:79)
        ... 136 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
e class definition: test/BusinessOrganization_$$_
javassist_272
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
        ... 137 more
Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
        at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
        ... 138 more

  was:
Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.

The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.

Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
s definition: test/BusinessOrganization_$$_javass
ist_272
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
        at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
JavassistLazyInitializer.java:79)
        ... 136 more
Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
e class definition: ch/logobject/mlogistics/om/resource/BusinessOrganization_$$_
javassist_272
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
        at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
        ... 137 more
Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
        at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
        ... 138 more


> Javassist lazy proxy factoring not thread-safe
> ----------------------------------------------
>
>                 Key: HIBERNATE-46
>                 URL: http://jira.jboss.com/jira/browse/HIBERNATE-46
>             Project: Hibernate
>          Issue Type: Bug
>         Environment: JBoss AS 4.0.4 with EJB 3-RC8
>            Reporter: Ortwin Gl?ck
>         Assigned To: Steve Ebersole
>
> Multiple threads may simultanously (especially on SMP systems) create proxy classes for the first time. The JavassistLazyInitializer is not completely thread safe. So the first thread will successfully create the dynamic class, while a second thread may fail. We saw this happen a few times at JBoss startup when multiple messages from other systems arrived via JMS (quite normal when you take your PROD system down for some minutes, as work keeps queuing up). So multiple MDB threads were running the same transactions (using the same classes) and thus the probability for this error to occur is close to 100%.
> The situation can easily be solved by proper synchronization inside the JavassistLazyInitializer.
> Caused by: java.lang.RuntimeException: by java.lang.LinkageError: duplicate clas
> s definition: test/BusinessOrganization_$$_javass
> ist_272
>         at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:173)
>         at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.getProxy(
> JavassistLazyInitializer.java:79)
>         ... 136 more
> Caused by: javassist.CannotCompileException: by java.lang.LinkageError: duplicat
> e class definition: test/BusinessOrganization_$$_
> javassist_272
>         at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:125)
>         at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:169)
>         ... 137 more
> Caused by: java.lang.LinkageError: duplicate class definition: test/BusinessOrganization_$$_javassist_272
>         at java.lang.ClassLoader.defineClass1(Native Method)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>         at java.lang.ClassLoader.defineClass(ClassLoader.java:465)
>         at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at javassist.util.proxy.FactoryHelper.toClass(FactoryHelper.java:117)
>         ... 138 more

-- 
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

       



From jira-events at jboss.com  Sat Sep 16 11:52:47 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Sat, 16 Sep 2006 11:52:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-707)
 TreeCacheProviderHook.isMinimalPutsEnabledByDefault() wrong
Message-ID: <30441832.1158421967437.JavaMail.jira@cloud.prod.atl2.jboss.com>

TreeCacheProviderHook.isMinimalPutsEnabledByDefault() wrong
-----------------------------------------------------------

                 Key: EJBTHREE-707
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-707
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Owen Taylor
            Priority: Minor


org.jboss.ejb3.entity.TreeCacheProviderHook.isMinimalPutsEnabledByDefault()  returns false,
which means "don't check to see if values are in the cache before inserting them again", but
that's a very bad setting for the TreeCache

 - It causes unnecessary replication between the nodes of a cluster
 - It tends to cause lock conflicts because the transaction putting data
   into the cache has to get a (briefly) get a write lock. There are hacky workarounds in the
   hibernate TreeCache code not to deadlock in this code, but you still get log spew.

The TreeCacheProvider provided with Hibernate (no JMX integration) returns true 
isMinimalPutsEnabledByDefault() as it should, so I think this is just an oversight.

You can of course easily work around the problem by setting the value explicitly in the
hibernate properties.


-- 
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

        


From jira-events at jboss.com  Sat Sep 16 12:46:47 2006
From: jira-events at jboss.com (degerhar (JIRA))
Date: Sat, 16 Sep 2006 12:46:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-665) @PostConstruct
 throws NPE when EntityManager is used
In-Reply-To: <24188502.1153922291327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10863356.1158425207783.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-665?page=comments#action_12343414 ] 
            
degerhar commented on EJBTHREE-665:
-----------------------------------

Hi.

I have the same problem with Mandriva 10.2, JBoss-4.0.4.GA

I have a Timer that execute some SQL every minute via an entity manager.
The method in which this happen is exposed in JMX.

When I execute the method from the jmx-console, the SQL is executed fine.
When the Timer fires to execute the method, I get the NPE:

It seems the root cause of the problem is at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)

java.lang.NullPointerException
at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)
at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:163)
at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:125)
at com.yannitech.security.jmx.UserService.expireSessions(UserService.java:219)
at com.yannitech.security.jmx.UserService.checkSessions(UserService.java:131)
at com.yannitech.security.jmx.UserService.handleNotification(UserService.java:123)
at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
at $Proxy217.handleNotification(Unknown Source)
at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:221)
at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:184)
at javax.management.timer.Timer.sendNotification(Timer.java:1295)
at javax.management.timer.Timer.notifyAlarmClock(Timer.java:1264)
at javax.management.timer.TimerAlarmClock.run(Timer.java:1347)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)

Gerhard

> @PostConstruct throws NPE when EntityManager is used
> ----------------------------------------------------
>
>                 Key: EJBTHREE-665
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-665
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: Windows XP, JBoss 4.0.4.GA + EJB-3.0-RC8
>            Reporter: Steven Verze
>
> @PostConstruct method throws NPE when called on a stateless session bean.
> The method iteself accesses the enetity manager and tries create a query, the following exception is experienced:
> java.lang.RuntimeException: java.lang.NullPointerException
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:109)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getNonTxEntityManager(ManagedEntityManagerFactory.java:58)
> 	at org.jboss.ejb3.entity.ManagedEntityManagerFactory.getTransactionScopedEntityManager(ManagedEntityManagerFactory.java:163)
> 	at org.jboss.ejb3.entity.TransactionScopedEntityManager.createQuery(TransactionScopedEntityManager.java:125)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceBean.initialiseSpendCardQuery(SnapAccountSendProcessServiceBean.java:83)
> 	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.jboss.ejb3.interceptor.LifecycleInvocationContextImpl.proceed(LifecycleInvocationContextImpl.java:159)
> 	at org.jboss.ejb3.interceptor.LifecycleInterceptorHandler.postConstruct(LifecycleInterceptorHandler.java:105)
> 	at org.jboss.ejb3.EJBContainer.invokePostConstruct(EJBContainer.java:582)
> 	at org.jboss.ejb3.AbstractPool.create(AbstractPool.java:108)
> 	at org.jboss.ejb3.ThreadlocalPool.get(ThreadlocalPool.java:48)
> 	at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:54)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:227)
> 	at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
> 	at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:828)
> 	at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
> 	at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
> 	at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:398)
> 	at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
> 	at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:190)
> 	at org.jboss.remoting.Client.invoke(Client.java:525)
> 	at org.jboss.remoting.Client.invoke(Client.java:488)
> 	at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:55)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:78)
> 	at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
> 	at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
> 	at $Proxy3.getBatchNumbers(Unknown Source)
> 	at com.teleglobal.modules.snapaccount.services.SnapAccountSendProcessServiceTest.testGetBatchNumbers(SnapAccountSendProcessServiceTest.java:57)
> 	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 junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Here is a the post construct method:
> @PostConstruct
>     void initialiseSpendCardQuery()
> 	{		
> 		StringBuilder sendCardQueryString = new StringBuilder();    	
> 		sendCardQueryString.append("SELECT c FROM Card AS c WHERE c.status = 'U' AND c.batchNumber IN (");
> 		 
> 		long[] batchNumbers = getBatchNumbers();
> 		for (int i = 0; i < batchNumbers.length; i++)
> 		{
> 		    sendCardQueryString.append("?").append(i);
> 			if (i+1 < batchNumbers.length)
> 			    sendCardQueryString.append(",");
> 		}
> 		sendCardQueryString.append(") AND c NOT IN (SELECT lc.sendCard FROM SendCardLock AS lc)");
> 		sendCardQuery = entityManager.createQuery(sendCardQueryString.toString());
> 		 
> 		for (int i = 0; i < batchNumbers.length; i++)
> 			sendCardQuery.setParameter(i, batchNumbers[i]);		
> 	}
> It happens when the entityManager is used.

-- 
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

        


From global888 at yahoo.com  Sun Sep 17 02:28:06 2006
From: global888 at yahoo.com (ªÔ³Õ¹Øª)
Date: Sun, 17 Sep 2006 02:28:06
Subject: [jboss-jira] =?iso-8859-1?q?Now!_=CD=B9=D2=A4=B5=A2=CD=A7=A4=D8?=
	=?iso-8859-1?q?=B3=C3=CD=E4=C1=E8=E4=B4=E9=E1=C5=E9=C7?=
Message-ID: <200609161928.k8GJRnI8026654@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060917/c2d7b880/attachment-0001.html 

From jira-events at jboss.com  Sat Sep 16 19:34:48 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Sat, 16 Sep 2006 19:34:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1004) Jboss Portal
 to support virtual hosts
In-Reply-To: <16944436.1156894064053.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2663141.1158449688561.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1004?page=comments#action_12343416 ] 
            
Sverker Abrahamsson commented on JBPORTAL-1004:
-----------------------------------------------

I've done some more investigations and see that the first solution with separate contexts is the way to go. Why? Because isolation is needed between the applications.

With the implementation where the virtual-host/context-path information is bound to the Portal object then if I deploy my portal to http://portaltest.abrahamsson.com then I can access the default portal on http://portaltest.abrahamsson.com/portal/default/. Well, sort of since the portlets are rendered but images etc can't be loaded, since they are in a different web application context.

That is essentially the point, like the servlet container maintains different contexts to isolate different applications so does the portal server need to do. This turned out to work supprisingly well in the first approach I did, the rest of the app seams to be designed with multiple contexts in mind even if the model isn't.

What needs to be discussed is how it should be specified in the *-object.xml file which context a portal should be deployed to. I find that the most logical is that unless a parent ref is specified then it should be bound to the context created by the war. If the parent ref is empty (i.e. <parentref/>) then the portal is bound to the default context and if a specific parent is specified then the it is bound to that context. This is also consistent with how things have worked historically.

I've done some basic testing on letting the portals having different security domains which seams to work fine but needs further analysis, especially how it affects the cms.

Note that the ObjectNodes still form a tree, with the default context as root and the other contextes as children to it.

> Jboss Portal to support virtual hosts
> -------------------------------------
>
>                 Key: JBPORTAL-1004
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1004
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Sverker Abrahamsson
>         Attachments: jboss-portal-2.4-2.patch, jboss-portal-2.4.patch, new.files.zip
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> JBoss Portal is today unable to support multiple virtual hosts, i.e. it's not possible to create a portal bound to the address www.foo.com and one that is bound to www.bar.com.
> This is a major problem for real world usage of JBoss Portal

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 21:06:47 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 16 Sep 2006 21:06:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1040) Enhancements to
	DnD
In-Reply-To: <26504714.1158328240036.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2354631.1158455207492.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1040?page=all ]

Roy Russo resolved JBPORTAL-1040.
---------------------------------

    Resolution: Done

> Enhancements to DnD
> -------------------
>
>                 Key: JBPORTAL-1040
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1040
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> 1. fix ordering to insert at the bottom-most area (after the last portlet).
> 2. dotted line cleanup.. 
>     a. Either default to a simple insertion line, or
>     b. try to simulate netvibes behaviour, of moving all below windows down and showing a highlighted target area.
> 3. cleanup messy and ill-performant code. (StringBuffers are your friend)
> 4. title bars, only, should be clickable for dragging.
> 5. Cursor should change to *something* when over a draggable region (before clicking).

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 21:20:47 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 16 Sep 2006 21:20:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1042) Add AJAX request
	Javascript
Message-ID: <13107312.1158456047454.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add AJAX request Javascript
---------------------------

                 Key: JBPORTAL-1042
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1042
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


Add DOM walker and storing of original values, and try to supply this to backend:

- window id/window name
- source coordinates (region / index)
- destination coordinates (regin / index)



-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:00:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:00:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-685) Integration using
 the new Cache2.0 API and SPI
Message-ID: <5483479.1158462047510.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-685?page=all ]

Ben Wang resolved JBCACHE-685.
------------------------------

    Resolution: Done

> Integration using the new Cache2.0 API and SPI
> ----------------------------------------------
>
>                 Key: JBCACHE-685
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-685
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Currently, PojoCache 2.0 development is still using the old TreeCache API. It would be nice to migrate to 2.0 API when it is completed.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:00:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:00:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-584) Investigate use of
 lazy mapping for PojoCache
Message-ID: <3358098.1158462047621.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-584?page=all ]

Ben Wang updated JBCACHE-584:
-----------------------------

    Fix Version/s: PojoCache 2.1.0
                       (was: PojoCache 2.2.0)

> Investigate use of lazy mapping for PojoCache
> ---------------------------------------------
>
>                 Key: JBCACHE-584
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-584
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Recent perf test on PojoCache shows bottleneck is on the initial mapping of putObject causing numerous trips to the local cache store. To optimize it further, either the TreeCache local mode need to be enhanced. Or one solution to this is the use of lazy mapping of the pojo. For example, when putObject is called, pojo is not mapped. Instead, it is stored under a "Serialized" state (can use JBossSerialization if  pojo is not even Seriailizable) first. Then when the field is modified (detected from the CacheInterceptor), we will then map it lazily to the PojoCache store.
> The performance gain can be had, if 1) initial saving of mapping, 2) field update is only selected.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:02:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:02:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-450) Create a pure
 pojo-based eviction policy
Message-ID: <7406915.1158462167463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-450?page=all ]

Ben Wang updated JBCACHE-450:
-----------------------------

    Fix Version/s: 2.0.0
                       (was: PojoCache)

> Create a pure pojo-based eviction policy
> ----------------------------------------
>
>                 Key: JBCACHE-450
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-450
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> The eviction policy module has been refactored in 1.3. We will need to refactor the pojo-based evitction policy as well.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:06:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:06:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-750) PojoCache to deal
 with POJO without no-arg constructor
In-Reply-To: <3891836.1156726004669.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31770532.1158462407583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-750?page=all ]

Ben Wang updated JBCACHE-750:
-----------------------------

    Fix Version/s: PojoCache 2.1.0
                       (was: PojoCache)

> PojoCache to deal with POJO without no-arg constructor
> ------------------------------------------------------
>
>                 Key: JBCACHE-750
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-750
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> This came up from a forum post that uses SynchronizedCollection. Here is the problem that Professor Chiba pointed out:
> ------
> Ben,
> SynchronizedRandomAccessList class has only the following constructors:
> static class SynchronizedRandomAccessList<E>
>          extends SynchronizedList<E>
>          implements RandomAccess {
>          SynchronizedRandomAccessList(List<E> list) {
>              super(list);
>          }
>          SynchronizedRandomAccessList(List<E> list, Object mutex) {
>              super(list, mutex);
>          }
>                 :
> }
> I can modify Javassist so that the above constructors (visible only within the pacakge) will be copied to the generated class.  But I am not sure that PojoCache can work with that generated class since it does not have a no-arg constructor.
> Chiba
> --------
> No easy solution to this problem now. Maybe use the exisiting serialization for once during replication?

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-157) Use privileged
 action in CacheInterceptor
Message-ID: <27732451.1158462528029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-157?page=all ]

Ben Wang updated JBCACHE-157:
-----------------------------

    Fix Version/s: 2.1.0
                       (was: 2.0.0)

This should be implemented along the overall context of JBoss Cache not just PojoCache.

> Use privileged action in CacheInterceptor
> -----------------------------------------
>
>                 Key: JBCACHE-157
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-157
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2.2
>         Environment: Standalone JDK 1.5 application with custom security policy
>            Reporter: twundke
>         Assigned To: Ben Wang
>             Fix For: 2.1.0
>
>         Attachments: CacheInterceptor.patch
>
>
> When using the AOP version of JBoss Cache in a security-managed environment, various classes require certain permissions (such as org.jboss.cache.aop.CachedType requiring java.lang.RuntimePermission "accessDeclaredMembers"). This also means that any class accessing a cached object must be granted these permissions.
> There are a number of problems with this. The first is that it breaks the transparency of using AOP-ed objects with the cache, as users of these objects must be granted additional permissions. The second problem is the nature of the permissions that must be granted. They are powerful permissions that allow runtime reflection, and in my particular case cannot be granted to the code using cached objects.
> The solution is to wrap the CacheInterceptor.invoke() method in a call to AccessController.doPrivileged() when a security manager is present. This allows the necessary permissions to be granted to the cache, without affecting the permissions of the calling code.
> The attached patch does just that. However, I don't know if this will have an effect on using the cache within a managed environment. I suspect not, but have no way of testing this.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-30) Multiple MBean
 Configuration Error
Message-ID: <4160664.1158462528183.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-30?page=all ]

Ben Wang resolved JBCACHE-30.
-----------------------------

    Resolution: Out of Date

This will be out of date with our 2.0 release.

> Multiple MBean Configuration Error
> ----------------------------------
>
>                 Key: JBCACHE-30
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-30
>             Project: JBoss Cache
>          Issue Type: Bug
>    Affects Versions: 1.2
>            Reporter: SourceForge User
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> SourceForge Submitter: jiwils .
> Some if not all of the JBossCache configuration XML
> files contain the following commented MBean definition:
> <!--  Uncomment to get a graphical view of the
> TreeCache MBean above -->
>    <!--   <mbean code="org.jboss.cache.TreeCacheView"
> name="jboss.cache:service=TreeCacheView">-->
>    <!--     
> <depends>jboss.cache:service=TreeCache</depends>-->
>    <!--      <attribute
> name="CacheService">jboss.cache:service=TreeCache</attribute>-->
>    <!--   </mbean>-->	
> By uncommenting this MBean definition, I thought I
> would get a GUI with which I could inspect the cache,
> but instead I got a "multiple MBean" exception.

-- 
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

        


From jira-events at jboss.com  Sat Sep 16 23:10:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 16 Sep 2006 23:10:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-589) PojoCache pojo
 level locking semantics
Message-ID: <26780947.1158462647407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-589?page=all ]

Ben Wang resolved JBCACHE-589.
------------------------------

    Resolution: Done

This is done via TxLockInterceptor.

> PojoCache pojo level locking semantics
> --------------------------------------
>
>                 Key: JBCACHE-589
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-589
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> When using pessimistic locking, we need to provide a pojo level locking semantics. Current one uses only node level and there is big problem when the node is not yet exist since we can't lock it that way. Idea maybe to provide an extra lock interceptor that tracks the pojo-level locking.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 02:22:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 02:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-695) PojoCache
 transaction context has limitation for in-memory rollbakck
In-Reply-To: <7160873.1152866171389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25504467.1158474167709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-695?page=all ]

Ben Wang updated JBCACHE-695:
-----------------------------

       Summary: PojoCache transaction context has limitation for in-memory rollbakck  (was: PojoCache transaction rollback has limitation under certain transaction context)
    Complexity: High

> PojoCache transaction context has limitation for in-memory rollbakck
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-695
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-695
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Currently PojoCache supports transaction rollback. For instance,
> cache.attach(id, pojo);
> is transactional even if there is no user transaction. However, with user transaction,
> tx.begin();
> cache.attach(id, pojo);
> pojo.setAge(20);
> tx.rollback();
> the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself:
> // Just make sure this one succeeds first.
> tx.begin();
> cache.attach(id, pojo);
> tx.commit();
> // All subsquent field update will be transactional then.
> tx.begin();
> pojo.setAge(20);
> tx.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

        


From jira-events at jboss.com  Sun Sep 17 02:22:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 02:22:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-695) PojoCache
 transaction context has limitation for in-memory rollbakck
In-Reply-To: <7160873.1152866171389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6215673.1158474168159.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-695?page=all ]

Ben Wang resolved JBCACHE-695.
------------------------------

    Resolution: Done

Has a InMemoryTxUndoTest to validate this. All in-memory state rollback should be handled properly as well.

> PojoCache transaction context has limitation for in-memory rollbakck
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-695
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-695
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Currently PojoCache supports transaction rollback. For instance,
> cache.attach(id, pojo);
> is transactional even if there is no user transaction. However, with user transaction,
> tx.begin();
> cache.attach(id, pojo);
> pojo.setAge(20);
> tx.rollback();
> the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself:
> // Just make sure this one succeeds first.
> tx.begin();
> cache.attach(id, pojo);
> tx.commit();
> // All subsquent field update will be transactional then.
> tx.begin();
> pojo.setAge(20);
> tx.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

        


From jira-events at jboss.com  Sun Sep 17 03:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-757) Problem updating
 cyclic reference
In-Reply-To: <30339271.1156937625656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22540775.1158476928808.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-757?page=all ]

Ben Wang resolved JBCACHE-757.
------------------------------

    Resolution: Done

> Problem updating cyclic reference
> ---------------------------------
>
>                 Key: JBCACHE-757
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-757
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: J?rn Eyrich
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> import org.jboss.cache.aop.PojoCache;
> import org.jboss.cache.aop.annotation.PojoCacheable;
> @PojoCacheable
> public class Main {
> 	public Main reference;
> 	
> 	public static void main(String[] args) throws Exception {
> 	
> 		PojoCache cache = new PojoCache();
> 		cache.startService();
> 		
> 		Main main  = new Main();
> 		Main main2 = new Main();
> 		main.reference  = main2;
> 		main2.reference = main;
> 		
> 		cache.putObject("/main",main);
> 		main2.reference = main; // <--
> 		System.out.println("Done...");
> 	}
> }
> results in:
> Exception in thread "main" java.lang.RuntimeException: PojoCache.putObject(): fqn: /main/reference/reference
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478)
> 	at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:115)
> 	at org.jboss.aop.joinpoint.FieldWriteInvocation.invokeNext(FieldWriteInvocation.java:51)
> 	at Main.reference_w_$aop(Main.java)
> 	at Main.main(Main.java:21)
> Caused by: java.lang.IllegalStateException: AOPInstance.incrementRefCount(): source fqn: /main/reference/reference is already present.
> 	at org.jboss.cache.aop.AOPInstance.incrementRefCount(AOPInstance.java:92)
> 	at org.jboss.cache.aop.InternalDelegate.incrementRefCount(InternalDelegate.java:98)
> 	at org.jboss.cache.aop.ObjectGraphHandler.incrementRefCount(ObjectGraphHandler.java:212)
> 	at org.jboss.cache.aop.ObjectGraphHandler.setupRefCounting(ObjectGraphHandler.java:192)
> 	at org.jboss.cache.aop.ObjectGraphHandler.objectGraphPut(ObjectGraphHandler.java:88)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:201)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	... 4 more

-- 
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

       



From jira-events at jboss.com  Sun Sep 17 03:08:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:08:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-757) Problem updating
 cyclic reference
In-Reply-To: <30339271.1156937625656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4693780.1158476928480.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-757?page=comments#action_12343423 ] 
            
Ben Wang commented on JBCACHE-757:
----------------------------------

I have verified this in 2.0 release:

   public void testCircularReference8() throws Exception
   {
      log.info("testCircularReference8() ...");
      Link parent = new Link("parent");
      Link child = new Link("child");
      parent.setLink(child);
      child.setLink(parent);

      cache_.attach("parent", parent);
      parent.setLink(child); // again
      child.setLink(parent);
   }

and it works fine.

> Problem updating cyclic reference
> ---------------------------------
>
>                 Key: JBCACHE-757
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-757
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: J?rn Eyrich
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> import org.jboss.cache.aop.PojoCache;
> import org.jboss.cache.aop.annotation.PojoCacheable;
> @PojoCacheable
> public class Main {
> 	public Main reference;
> 	
> 	public static void main(String[] args) throws Exception {
> 	
> 		PojoCache cache = new PojoCache();
> 		cache.startService();
> 		
> 		Main main  = new Main();
> 		Main main2 = new Main();
> 		main.reference  = main2;
> 		main2.reference = main;
> 		
> 		cache.putObject("/main",main);
> 		main2.reference = main; // <--
> 		System.out.println("Done...");
> 	}
> }
> results in:
> Exception in thread "main" java.lang.RuntimeException: PojoCache.putObject(): fqn: /main/reference/reference
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:478)
> 	at org.jboss.cache.aop.CacheInterceptor.invoke(CacheInterceptor.java:115)
> 	at org.jboss.aop.joinpoint.FieldWriteInvocation.invokeNext(FieldWriteInvocation.java:51)
> 	at Main.reference_w_$aop(Main.java)
> 	at Main.main(Main.java:21)
> Caused by: java.lang.IllegalStateException: AOPInstance.incrementRefCount(): source fqn: /main/reference/reference is already present.
> 	at org.jboss.cache.aop.AOPInstance.incrementRefCount(AOPInstance.java:92)
> 	at org.jboss.cache.aop.InternalDelegate.incrementRefCount(InternalDelegate.java:98)
> 	at org.jboss.cache.aop.ObjectGraphHandler.incrementRefCount(ObjectGraphHandler.java:212)
> 	at org.jboss.cache.aop.ObjectGraphHandler.setupRefCounting(ObjectGraphHandler.java:192)
> 	at org.jboss.cache.aop.ObjectGraphHandler.objectGraphPut(ObjectGraphHandler.java:88)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:201)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	... 4 more

-- 
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

       



From jira-events at jboss.com  Sun Sep 17 03:14:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-695) PojoCache
 transaction context has limitation for in-memory rollbakck
In-Reply-To: <7160873.1152866171389.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28250366.1158477287538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-695?page=all ]

Ben Wang updated JBCACHE-695:
-----------------------------

    Priority: Critical  (was: Major)

> PojoCache transaction context has limitation for in-memory rollbakck
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-695
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-695
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> Currently PojoCache supports transaction rollback. For instance,
> cache.attach(id, pojo);
> is transactional even if there is no user transaction. However, with user transaction,
> tx.begin();
> cache.attach(id, pojo);
> pojo.setAge(20);
> tx.rollback();
> the replication is rollbacked but the in-memory copy is not, e.g., pojo.getAge() == 20. There is a workaround if you are using transaction by yourself:
> // Just make sure this one succeeds first.
> tx.begin();
> cache.attach(id, pojo);
> tx.commit();
> // All subsquent field update will be transactional then.
> tx.begin();
> pojo.setAge(20);
> tx.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

        


From jira-events at jboss.com  Sun Sep 17 03:50:47 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sun, 17 Sep 2006 03:50:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-322) Provide 3 major
 default configurations (udp.xml, tcp.xml and tcp-nio.xml)
Message-ID: <7218240.1158479447973.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)
-------------------------------------------------------------------------

                 Key: JGRP-322
                 URL: http://jira.jboss.com/jira/browse/JGRP-322
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.2.9 SP4


Those configs should be the same in stacks.xml (for the Multiplexer) as well

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 03:58:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 03:58:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-765) implementation of
 equals() in collections is incorrect
In-Reply-To: <7801872.1158075576871.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21258593.1158479928437.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-765?page=all ]

Ben Wang resolved JBCACHE-765.
------------------------------

    Fix Version/s: 1.4.0.SP2
       Resolution: Done

Niztan, thanks!

> implementation of equals() in collections is incorrect
> ------------------------------------------------------
>
>                 Key: JBCACHE-765
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-765
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 1.4.0.SP2, 2.0.0
>
>         Attachments: CachedListAbstract.java, CachedListAbstract.java, CachedMapImpl.java, CachedMapImpl.java
>
>
> The implementation of equals() is in PojoCache collections (List, Map) is incorrect (inconsistent with the List and Map interfaces behavior):
> In Map, equals() returns true for two maps that have the same keys but different mapping (e.g., map1 = ["ID", "1"], map2 = "ID", "2"]).
> In List, equals() returns true for two lists that have the same elements but in a different order (e.g., list1 = [1][2], list2 = [2][1]).

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 04:06:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 04:06:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-763) Transaction
 rollback does not
 restore contents of collection of cached collections
In-Reply-To: <17010858.1158053140337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10933467.1158480408050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-763?page=all ]

Ben Wang resolved JBCACHE-763.
------------------------------

    Resolution: Done

Fixed in 2.0. Test case is integrated into src-50/functional/o.j.c.pojo.rollback.MapTxUndoTest

> Transaction rollback does not restore contents of collection of cached collections
> ----------------------------------------------------------------------------------
>
>                 Key: JBCACHE-763
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-763
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: PojoCollectionRollbackTest.java
>
>
> In PojoCache, transaction rollback does not restore (by completely undoing modifications) the contents of a cached collection when the updated element is in itself a cached collection.
> 1. create 2 "data elements" in the cache which are Map instances.
> 2. create a "data elements container" in the cache which is a Map instance.
> 3. initalize the container with one data element.
> 4. in a transaction, replace the initial data element in the container with the other data element, and then rollback the transaction.
> After the rollback the element in the container is neither the new data element nor the old data element.
> It looks like the aopInstance reference in the internal CachedMapInterceptor is not restored by the rollback and contains null after it.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 04:30:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 04:30:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-760) TreeCacheListener
 in PojoCache gets nodeModify events for invalid objects
In-Reply-To: <14004858.1157453069075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7258900.1158481847908.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-760?page=all ]

Ben Wang resolved JBCACHE-760.
------------------------------

    Resolution: Done

1. Checked in both the test case and fix to 1.4.0SP2
2. Also fix it in 2.0. However, the notification event is different is 2.0 now.

> TreeCacheListener  in PojoCache gets nodeModify events for invalid objects
> --------------------------------------------------------------------------
>
>                 Key: JBCACHE-760
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-760
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.4.0.SP1
>            Reporter: Nitzan Niv
>         Assigned To: Ben Wang
>             Fix For: 1.4.0.SP2, 2.0.0
>
>         Attachments: CollectionClassHandler.java, TreeCacheAopListenerTest.java, TreeCacheAopListenerTest.java
>
>
> In PojoCache with a registered event listener, when inserting a collection (Map, List) to the cache, the listener gets events for the creation and then the modification of the collection object. On a nodeModify() event (with pre==false), if you call the cache's getObject with the received fqn you get the following runtime exception (which did not occur on 1.3.0SP2 in a similar scenario). 
> I believe the modification event is raised before the collection is "really" inserted into the cache, so the fqn points to an invalid object.
> java.lang.RuntimeException: TreeCacheAopDelegate._getObject(): null AOPInstance.
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObjectInternal(TreeCacheAopDelegate.java:122)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._getObject(TreeCacheAopDelegate.java:92)
> 	at org.jboss.cache.aop.PojoCache._getObject(PojoCache.java:722)
> 	at org.jboss.cache.aop.PojoCache.getObject(PojoCache.java:416)
> 	at org.jboss.cache.notifications.TreeCacheAopListenerTest$EventLog.nodeModify(TreeCacheAopListenerTest.java:268)
> 	at org.jboss.cache.TreeCache.notifyNodeModify(TreeCache.java:5832)
> 	at org.jboss.cache.TreeCache._put(TreeCache.java:4425)
> 	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:324)
> 	at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:321)
> 	at org.jboss.cache.interceptors.CallInterceptor.invoke(CallInterceptor.java:52)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:80)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
> 	at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
> 	at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
> 	at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
> 	at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5520)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3678)
> 	at org.jboss.cache.TreeCache.put(TreeCache.java:3349)
> 	at org.jboss.cache.aop.InternalDelegate.put(InternalDelegate.java:133)
> 	at org.jboss.cache.aop.InternalDelegate.putAopClazz(InternalDelegate.java:273)
> 	at org.jboss.cache.aop.CollectionClassHandler.collectionObjectPut(CollectionClassHandler.java:115)
> 	at org.jboss.cache.aop.TreeCacheAopDelegate._putObject(TreeCacheAopDelegate.java:213)
> 	at org.jboss.cache.aop.PojoCache._putObject(PojoCache.java:731)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:462)
> 	at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:423)
> To recreate the problem I use a test case similar to TreeCacheListenerTest but with a PojoCache. The test is:
>    public void testNodeCreatedAndModifiedMapEvent() throws Exception {
>        EventLog el = new EventLog(cache);
>        cache.addTreeCacheListener(el);
>        Map data = new HashMap();
>        data.put("key", "value");
>        cache.putObject("/hello/world", data);
>        ...
>   }
>  and the relevant listener code:
>       public void nodeModify(Fqn fqn, boolean pre, boolean isLocal)  {
>          events.add("modify "+
>                  (pre? "about to modify " : "Modified ") +
>                  (isLocal? "local " : "remote ") + fqn);
> 		 if(this.cache != null && !pre) {
> 			try {
> 				cache.getObject(fqn);
> 			}
> 			catch (Exception e) {
> 				events.add(e);
>                 e.printStackTrace(System.err);
> 			}
> 		 }
>       }

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 05:25:39 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 17 Sep 2006 05:25:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-771) PojoCache to have
 events reacting to transactional context
Message-ID: <5459146.1158485139891.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to have events reacting to transactional context
----------------------------------------------------------

                 Key: JBCACHE-771
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-771
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.1.0


Currently, the 2.0 POJO based events are not tx aware meaning they can't not react to tx rollback (and therefore not sending the events). If we want to acheieve the tx-based events, we will need to use event interceptor and react to before and afterCompletion, perhaps.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 05:29:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 05:29:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2619) Add a testcase to
 validate that a
 registering deployer can take priority over accepting deployments for which
 a deployer already exists
Message-ID: <2562581.1158485379955.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2619?page=all ]

Dimitris Andreadis updated JBAS-2619:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> Add a testcase to validate that a registering deployer can take priority over accepting deployments for which a deployer already exists
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2619
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2619
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Dimitris Andreadis
>
> EJB3Deployer needs to make sure it can process deployments *before* the 2.1 EJBDeployer.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:09:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:09:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3618) repository-zip target
 in
 build-release.xml doesn't consistently overwrite default config with all
In-Reply-To: <18718633.1157144863997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1764377.1158487778485.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3618?page=all ]

Dimitris Andreadis closed JBAS-3618.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

Added the overwrite=true flag

> repository-zip target in build-release.xml doesn't consistently overwrite default config with all
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3618
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3618
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Alex Pinkin
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
>    <target name="repository-zip"
>      description="Create a canonical binaries for the repository">
>      <mkdir dir="${version}/repository" />
>      <echo message="jboss.dist=${jboss.dist}" />
>      <!-- Create a unified server/lib directory -->
>      <copy todir="${jboss.dist}/server/lib">
>        <fileset dir="${jboss.dist}/server/minimal/lib" />
>        <fileset dir="${jboss.dist}/server/default/lib" />
>        <fileset dir="${jboss.dist}/server/all/lib" />
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.thirdparty}/quartz/lib" />
>      </copy>
>      <!-- Create a unified server/deploy directory -->
>      <copy todir="${jboss.dist}/server/deploy">
>        <fileset dir="${jboss.dist}/server/default/deploy" />
>        <fileset dir="${jboss.dist}/server/all/deploy">
>          <exclude name="jms/**" />
>        </fileset>
>        <!-- Include the prematurely added quartz stuff for ejb3 config -->
>        <fileset dir="${jboss.cvs.dir}/connector/output/lib">
>          <include name="quartz-ra.rar" />
>        </fileset>
>      </copy>
>      <copy todir="${jboss.dist}/server/deploy-ha">
>        <fileset dir="${jboss.dist}/server/all">
>          <include name="deploy/jms/**" />
>          <include name="deploy-hasingleton/**" />
>          <include name="farm/**" />
>        </fileset>
>      </copy>
> Ant's copy task only overwrites a file only if a file being copied has a newer timestamp. This causes inconsistent behavior depending on file timestamps.
> There is overwrite=true attribute which need to be added to force overwrites.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:19:39 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:19:39 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1714) -service.xml not
 deploying deploy/*.jar correctly
Message-ID: <12956311.1158488379438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1714?page=all ]

Dimitris Andreadis closed JBAS-1714.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Won't Fix

the classpath element is rarely used.

> -service.xml not deploying deploy/*.jar correctly
> -------------------------------------------------
>
>                 Key: JBAS-1714
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1714
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>            Reporter: SourceForge User
>
> SourceForge Submitter: ioparra .
> Refer to my previous postings in the forums:
> http://www.jboss.org/thread.jsp?
> forum=63&thread=36306
> The SAR Deployer is locking down jars in the deploy 
> directory instead of deploying those jars correctly.  This 
> event occurs when you have a "classpath" entry in your 
> mbean.  If that classpath has a codebase="."(ie, its 
> codebase is the deploy directory), this SAR Deployer 
> adds this jar to UCL repository.  
> Issues:
> 1)the url for this jar points to the deploy directory(not a 
> temp directory)
>     a. when the service is run, this jar is no longer 
> deleteable(on windows, dunno about unix).
> 2)The DirectoryScanner picks up this jar while scan.  
> The scanner copies/deploys the jar from the tmp 
> directory, leading to a new/managed UCL.  The 
> UCLRepository doesn't know its a duplicate becuase it 
> compares the URLs(one url is from deploy, the other 
> from tmp).
> Possible work-around/solution:
> The SAR deployer already does a check if the 
> classpath="."(ie, the deploy directory).  If true, call 
> mainDeployer.deploy(url) and don't call addURL.  I 
> don't know the full implications of making this change.  
> If I have time, I'll try it out and post a patch.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:23:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:23:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-293) dynamic-ql sort order
	problem
Message-ID: <16299038.1158488618097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-293?page=all ]

Dimitris Andreadis updated JBAS-293:
------------------------------------

      Component/s: CMP service
                       (was: EJB2)
    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> dynamic-ql sort order problem
> -----------------------------
>
>                 Key: JBAS-293
>                 URL: http://jira.jboss.com/jira/browse/JBAS-293
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>            Reporter: SourceForge User
>
> SourceForge Submitter: s2jcpete .
> Conectiva 8.0 
> JBoss-3.0.4 
> j2sdk-1.4.0_02 
>  
> When executing a dynamic-ql query in my CMP2.0 bean 
> everything gets returned correctly, but there is an issue with 
> the sorting.  It will not return the data properly sorted no 
> matter what field I ask to sort, or the ASC/DESC.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:25:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:25:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1535) PK Constraint name
 for Datbase Derby to long
Message-ID: <20712369.1158488739000.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1535?page=all ]

Dimitris Andreadis updated JBAS-1535:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> PK Constraint name for Datbase Derby to long
> --------------------------------------------
>
>                 Key: JBAS-1535
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1535
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.1 Final
>         Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded
>            Reporter: Ingo Bruell
>             Fix For: JBossAS-4.0.6.CR1
>
>
> In creating time of tables it could happen that a generated name for a pk constraint exceeds the limit of 18 characters.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:27:43 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:27:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1536) Wrong SQL Type for
 Boolean Mapping for Derby Database
Message-ID: <24271762.1158488863133.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1536?page=all ]

Dimitris Andreadis updated JBAS-1536:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Wrong SQL Type for Boolean Mapping for Derby Database
> -----------------------------------------------------
>
>                 Key: JBAS-1536
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1536
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.1 Final
>         Environment: JBoss4.0.1; JDK1.5.0update1;Windows XP SP2;Derby 10.0.2.1 Embedded
>            Reporter: Ingo Bruell
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The SQL datatype 'BOOLEAN' is not a valid datatype for the derby database.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:29:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:29:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2193) abstract schema name
 with word limit in name
Message-ID: <29304285.1158488978694.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ]

Dimitris Andreadis updated JBAS-2193:
-------------------------------------

    Component/s:     (was: EJB2)
       Assignee: Alexey Loubyansky
       Priority: Minor  (was: Major)

> abstract schema name with word limit in name
> --------------------------------------------
>
>                 Key: JBAS-2193
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2193
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions:  JBossAS-4.0.3RC1
>         Environment: OS: Windows XP and FreeBsd
> Database: PostgreSQL 7.4
>            Reporter: Yura Kravchuk
>         Assigned To: Alexey Loubyansky
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly.
> Herewith exception:
> 17:02:28,671 INFO  [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ
> ory; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.
> Was expecting:
>     "FROM" ...
>     ; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 06:31:38 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 17 Sep 2006 06:31:38 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3596) JNDI static cache
In-Reply-To: <3008714.1157125304199.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6820712.1158489098486.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3596?page=all ]

Dimitris Andreadis updated JBAS-3596:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

If you want to investigate this for the next release, otherwise, close it.

> JNDI static cache
> -----------------
>
>                 Key: JBAS-3596
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3596
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>             Fix For: JBossAS-5.0.0.CR1, JBossAS-4.0.6.CR1
>
>
> Having a JNDI caching would improove performance on applications where JNDI is over used.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 09:12:47 2006
From: jira-events at jboss.com (Jason Lenhart (JIRA))
Date: Sun, 17 Sep 2006 09:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31150283.1158498767507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Jason Lenhart closed JBESB-128.
-------------------------------

    Resolution: Done

I looked through the current docs and it appears to been taken out.

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 09:14:47 2006
From: jira-events at jboss.com (Jason Lenhart (JIRA))
Date: Sun, 17 Sep 2006 09:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-129) Wrong jar referred to
 in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16229392.1158498887468.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Jason Lenhart closed JBESB-129.
-------------------------------

    Resolution: Done

Per Mark's comment, I added the following to the docs:

"We have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes."

We should probably just say that we have provided a driver - as the name on this will inevitably change.


> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 10:02:47 2006
From: jira-events at jboss.com (Mohit Keswani (JIRA))
Date: Sun, 17 Sep 2006 10:02:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-68) Tidy-up JDBC classes
Message-ID: <22834488.1158501767849.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mohit Keswani closed JBESB-68.
------------------------------

    Fix Version/s: 4.0 Beta 1
                       (was: 4.0)
       Resolution: Done

Modified all helpers/persist classes to throw SQLException
Modified method names to make them complete and logical.

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 13:44:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sun, 17 Sep 2006 13:44:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-354) Better support for
 JSF-style managed properties
In-Reply-To: <28874974.1158345394933.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13368840.1158515087461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-354?page=all ]

Gavin King closed JBSEAM-354.
-----------------------------

    Resolution: Rejected

Negative, this is already available with @RequestParameter, which is the only time it is useful (and is exactly the example you use). You will never need it any other time you use @In.

> Better support for JSF-style managed properties
> -----------------------------------------------
>
>                 Key: JBSEAM-354
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-354
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 1.0.1
>            Reporter: Adam Brod
>            Priority: Minor
>
> The @In annotation should support the same syntax as JSF managed properties.  That means that If I have this annotation in my Bean:
> @In("#{param.fileId}")
> Long fileId
> Seam should automatically inject that property performing the correct JSF conversion.  In Shale I can do that with the @Value or @Property annotation.  It is very confusing that I need a specialized annotation that doesn't support the EL just for request parameters when JSF doesn't make that distinction.
> I believe this could be implemented with a few small changes to Component.  Inside Component.getInstanceToInject(...), the logic which first checks to see if the name is an EL (line 1358 in Seam 1.0.1) could also check to see if the expression begins with "#{param.", if so, then it can call to Component.convertRequestParameter(...) to convert the type.
> This is a small change to Component, but it makes the overall Seam API more consistent.  It allows me to use the EL anywhere I want.  I don't have to worry about using @In or @RequestParameter, I just use the EL.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 14:16:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 17 Sep 2006 14:16:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3662) Add TCP_NIO tests to
 tests-clustering-all-stacks
Message-ID: <1585833.1158517007452.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add TCP_NIO tests to tests-clustering-all-stacks
------------------------------------------------

                 Key: JBAS-3662
                 URL: http://jira.jboss.com/jira/browse/JBAS-3662
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering, Test Suite
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


The mulitiplexer-stacks.xml file will have UDP, TCP and TCP_NIO configs.  Testsuite should excercise all 3, not just UDP and TCP.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 14:36:47 2006
From: jira-events at jboss.com (Alex Burgel (JIRA))
Date: Sun, 17 Sep 2006 14:36:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-751) unnecessary warning
 on valid process definition
Message-ID: <8319176.1158518207502.JavaMail.jira@cloud.prod.atl2.jboss.com>

unnecessary warning on valid process definition
-----------------------------------------------

                 Key: JBPM-751
                 URL: http://jira.jboss.com/jira/browse/JBPM-751
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Alex Burgel
         Assigned To: Tom Baeyens
            Priority: Trivial


i get this warning:

process xml warning: warning: no swimlane or assignment specified for task '<task xmlns="urn:jbpm.org:jpdl-3.1" name="schedule" blocking="false" signalling="true" priority="normal"/>'

it seems a bit odd to generate a warning on a valid process definition.

i think it should either be illegal to have a task without an assignment or swimlane, or there shouldn't be any warning at all (maybe lower the logging level to INFO).

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 14:50:47 2006
From: jira-events at jboss.com (Alex Burgel (JIRA))
Date: Sun, 17 Sep 2006 14:50:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-752) hibernate warnings in
 update HQL statements
Message-ID: <7268249.1158519047540.JavaMail.jira@cloud.prod.atl2.jboss.com>

hibernate warnings in update HQL statements
-------------------------------------------

                 Key: JBPM-752
                 URL: http://jira.jboss.com/jira/browse/JBPM-752
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Alex Burgel
         Assigned To: Tom Baeyens
            Priority: Trivial


i'm seeing a bunch of hibernate warnings in jbpm 3.1.2, with hibernate 3.1.3:

FromElementType - Using non-qualified column reference [id -> ([ID_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [isSuspended -> ([ISSUSPENDED_])]
FromElementType - Using non-qualified column reference [token -> ([TOKEN_])]
FromElementType - Using non-qualified column reference [processInstance -> ([PROCESSINSTANCE_])]

they are caused by update HQL statements in org.jbpm.db.hibernate.queries.hbm.xml. i think for update statements you have to be explicit about column references. you have to specify the table name or alias for each column, otherwise you'll get these warnings.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 15:24:47 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sun, 17 Sep 2006 15:24:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-498) Optimised HashMap
 implementations
Message-ID: <15791394.1158521087854.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimised HashMap implementations
---------------------------------

                 Key: JBRULES-498
                 URL: http://jira.jboss.com/jira/browse/JBRULES-498
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Mark Proctor
         Assigned To: Mark Proctor
             Fix For: 3.1-m1


Create a HashMap implementation that is optimised for holding ReteTuples  and also for indexing FactHandles by field index  and value,

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 15:40:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Sun, 17 Sep 2006 15:40:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-772) State transfer not
 handled properly in case of reconnect
Message-ID: <1346641.1158522047451.JavaMail.jira@cloud.prod.atl2.jboss.com>

State transfer not handled properly in case of reconnect
--------------------------------------------------------

                 Key: JBCACHE-772
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-772
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: 1.4.0.SP1, 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.2.4SP2, 1.2.4SP1, 1.2.4
            Reporter: Brian Stansberry
         Assigned To: Manik Surtani
             Fix For: 2.1.0


In createService(), TreeCache set Channel.AUTO_GET_STATE to true.  This should only be done if the cache is configured to do an initial state transfer.

That's easy to fix.  What's harder to fix is what to do when region-based marshalling is in effect. Probably, something like the following:

1) In viewAccepted, monitor for the case where a view is issue that doesn't include the current node.  Set a flag and ??? (throw exceptions when attempts are made to use the cache???)
2) When another view is accepted that once again includes the current node, iterate through the various marshalling regions, inactivating and then reactivating them (reactivation will cause a partial state transfer).

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 17:52:48 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 17:52:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-99) Renderer/Portal
 support for the mbean management views
Message-ID: <9764091.1158529968073.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-99?page=all ]

Julien Viet resolved JBPORTAL-99.
---------------------------------

    Resolution: Rejected

> Renderer/Portal support for the mbean management views
> ------------------------------------------------------
>
>                 Key: JBPORTAL-99
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-99
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Alpha
>            Reporter: Scott M Stark
>
> How can the existing jmx-console be updated to allow the non-trivial attribute and operation types to have meaningful html views? See the JBAS-52 linked case for the immeadiate usecase of a HtmlEditor.toHtml() type of functionality I'm looking for.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:08:50 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:08:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPTL-14) Add new parsers
Message-ID: <4363853.1158530930050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-14?page=all ]

Julien Viet resolved JBPTL-14.
------------------------------

    Resolution: Rejected

> Add new parsers
> ---------------
>
>                 Key: JBPTL-14
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-14
>             Project: JBoss Portal
>          Issue Type: Sub-task
>            Reporter: Julien Viet
>            Priority: Optional
>
> Add new parsers to the stack like full HTML or wiki

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:14:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:14:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-240) make header data
 available to jsp includes
Message-ID: <14420650.1158531287270.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-240?page=all ]

Julien Viet resolved JBPORTAL-240.
----------------------------------

    Fix Version/s: 2.4.1 Final
                   2.6.Alpha1
       Resolution: Duplicate Issue

> make header data available to jsp includes
> ------------------------------------------
>
>                 Key: JBPORTAL-240
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-240
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.0 Beta 1
>            Reporter: joe hobson
>            Priority: Minor
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>
> The user-agent property is not currently being passed to the jsp that is included with the portlet's render response. According to the Building Portals with the Java Portlet API book, the request.getHeader() function should return the header from properties on the portlet request. I don't know enough about the JSR-168 spec to know whether this is a feature request or a bug. In JBP request.getHeader("user-agent") from an included jsp returns "null". Not sure about the other header info.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:18:48 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:18:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26073281.1158531528553.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Julien Viet reassigned JBPORTAL-998:
------------------------------------

    Assignee: Thomas Heute

Thomas, either apply it, or resolve it, thanks.


> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:18:48 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:18:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25520430.1158531528795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Julien Viet updated JBPORTAL-998:
---------------------------------

    Affects Version/s: 2.2.1 Final
                           (was: 2.4 Final)

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:20:46 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:20:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPTL-55) Create a little
	parser for emails
Message-ID: <16630998.1158531646637.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-55?page=all ]

Julien Viet resolved JBPTL-55.
------------------------------

    Resolution: Out of Date

> Create a little parser for emails
> ---------------------------------
>
>                 Key: JBPTL-55
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-55
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Heute
>            Priority: Minor
>
> Would be nice to have a little parser for things like sending an email.
> A simple text file like:
> Hello {givenName} {familyName},
> This is your password as you requested:
> Passord: {password}
> --
> Thanks,
> The team
> That would be easily customizable and it would have to be i18nized (different text files for different countries).
> MessageFormat could simply be the way to go.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:20:46 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:20:46 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5303775.1158531646771.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=all ]

Julien Viet updated JBPORTAL-1034:
----------------------------------

    Fix Version/s: 2.6.Alpha1

You forgot to fill in the "fix version", field, please do it next time.

> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 1 week, 2 hours
>
> - define architecture, goals and roadmap for portal - ldap integration
> - prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:22:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-680) JBoss Portal
 does not pass
 through request attributes to the underlying delegate HttpServletRequest
 anymore. This creates a problem with applications created with JSF
 (myfaces) as these applications use request attributes to write headers
Message-ID: <25640827.1158531767088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-680?page=all ]

Julien Viet resolved JBPORTAL-680.
----------------------------------

    Resolution: Out of Date

> JBoss Portal does not pass through request attributes to the underlying delegate HttpServletRequest anymore. This creates a problem with applications created with JSF (myfaces) as these applications use request attributes to write headers
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-680
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-680
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.0.2 Final
>         Environment: ALL
>            Reporter: Swarn Dhaliwal
>            Priority: Critical
>
> PortalRequestImpl class does not pass through the request attributes to underlying HttpServletJRequest anymore. This creates a problem with some components written in Myfaces as these components use
> request attributes to emit headers to the enclosing document.

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:22:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-305) How to define
 and extract user defined attributes in Jboss Portal/ portlet
Message-ID: <30198912.1158531767304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-305?page=all ]

Julien Viet resolved JBPORTAL-305.
----------------------------------

    Resolution: Rejected

JIRA is not a place to ask questions.

> How to define and extract user defined attributes in Jboss Portal/ portlet
> --------------------------------------------------------------------------
>
>                 Key: JBPORTAL-305
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-305
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>         Environment: Jboss portal 2.0
>            Reporter: David Huynh
>
> I have a few jsr 168 standard attributes defined in my porltet.xml; however, it  doesn't  show up when i try to  print out the user profile map even i have logged in. I  edit user profile and adde some values for some attributes and it start showing up but not first and last names, why?  Also, if  i want to define some attributes where i'm going to put them and how i extract them?  Thanks

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 18:22:47 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Sun, 17 Sep 2006 18:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-482) Secure context
 path for
 servlets using a servlet in the portal that proxies the request and
 dispatch it to the target context using the security provided by the portal
 war file
Message-ID: <20126804.1158531767430.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-482?page=all ]

Julien Viet resolved JBPORTAL-482.
----------------------------------

    Resolution: Rejected

Portlet 2.0 resource serving will provide that.

> Secure context path for servlets using a servlet in the portal that proxies the request and dispatch it to the target context using the security provided by the portal war file
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-482
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-482
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2 Final
>            Reporter: Julien Viet
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> This should provide more security for AJAX framework as the user identity should be propagated

-- 
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

        


From jira-events at jboss.com  Sun Sep 17 23:22:47 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Sun, 17 Sep 2006 23:22:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3650) LdapExtLoginModule
 still has connection leak
In-Reply-To: <26651737.1158120031293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20444213.1158549767549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3650?page=all ]

Prabhat Jha resolved JBAS-3650.
-------------------------------

    Assignee: JBN Patch Team  (was: Prabhat Jha)

It did not cause any regression. Here is the md5sum:

e1d378f52c7e7e1caf38ea88ff117406  jbosssx.jar


> LdapExtLoginModule still has connection leak
> --------------------------------------------
>
>                 Key: JBAS-3650
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3650
>             Project: JBoss Application Server
>          Issue Type: Support Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Scott M Stark
>         Assigned To: JBN Patch Team
>         Attachments: jbosssx.jar
>
>
> The fix to close all ldap contexts in JBAS-3448 still was leaving naming enumeration results open, which is delaying the close of connections to the next gc. We need to cleanup the ldap search result enumerations as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3662) Add TCP_NIO tests to
 tests-clustering-all-stacks
In-Reply-To: <1585833.1158517007452.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2052018.1158552767300.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3662?page=all ]

Brian Stansberry closed JBAS-3662.
----------------------------------

    Resolution: Done

> Add TCP_NIO tests to tests-clustering-all-stacks
> ------------------------------------------------
>
>                 Key: JBAS-3662
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3662
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.Beta
>
>
> The mulitiplexer-stacks.xml file will have UDP, TCP and TCP_NIO configs.  Testsuite should excercise all 3, not just UDP and TCP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3592) Add system property
 jgroups.mcast.ip_ttl
In-Reply-To: <13362282.1157048839355.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20326210.1158552767411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3592?page=all ]

Brian Stansberry closed JBAS-3592.
----------------------------------

    Resolution: Done

> Add system property jgroups.mcast.ip_ttl
> ----------------------------------------
>
>                 Key: JBAS-3592
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3592
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> Add a system property to all JGroups multicast configs in the AS to control ip_ttl.  Update testsuite build.xml to set this to 1 so running the testsuite doesn't send traffic off the box.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3587) Add a system property
 to configure TCPPING.initial_hosts
In-Reply-To: <19247726.1156955263825.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7604735.1158552767536.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3587?page=all ]

Brian Stansberry closed JBAS-3587.
----------------------------------

    Resolution: Done

> Add a system property to configure TCPPING.initial_hosts
> --------------------------------------------------------
>
>                 Key: JBAS-3587
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3587
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.CR1
>
>
> We want to make it easy to switch from a UDP-based JGroups config to a TCP-based one.  With the multiplexer this can be as simple as switching the multiplexer stack name in the various config files. One thing that makes the switch a pain is the need to configure initial_hosts in TCPPING.  We should make a system property to allow this to be externalized from the xml file, e.g:
> <TCPPING initial_hosts={${jgroups.tcp.initial_hosts:localhost[7800]} ...
> For now I'm going to go with just a system property.  If people want a startup switch they can request it.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:12:47 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 00:12:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3507) Add ability to toggle
 the MultiplexerStack between UDP- and TCP-based versions
In-Reply-To: <23746160.1155248952635.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33070177.1158552767668.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3507?page=all ]

Brian Stansberry closed JBAS-3507.
----------------------------------

    Resolution: Done

> Add ability to toggle the MultiplexerStack between UDP- and TCP-based versions
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-3507
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3507
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Need Branch_4_0-style "tests-clustering-all-stacks" tests, but simpler to implement due to ability to change the MultiplexerStack attribute.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:24:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:24:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-676) PojoCache map
 implementation needs to handle the case where key is PojoCacheable
Message-ID: <354515.1158553488593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-676?page=all ]

Ben Wang updated JBCACHE-676:
-----------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.)]

> PojoCache map implementation needs to handle the case where key is PojoCacheable
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-676
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-676
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> This is illustrated in org.jboss.cache.pojo.RecrusiveRefTest where we have map.put(valueId, valueObject) where both are PojoCacheable and valueId also embeded in valueObject. Therefore, if we treat valueId just as a Serializable, replication will cause the object reference split in valueObject (becuase in valueObject, valueId is treated by PojoCache).

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:24:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:24:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-676) PojoCache map
 implementation needs to handle the case where key is PojoCacheable
Message-ID: <28411056.1158553488780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-676?page=all ]

Ben Wang resolved JBCACHE-676.
------------------------------

    Resolution: Done

The test passes now in 2.0. Still need documentation of the effect of Id is Serializable only though.

> PojoCache map implementation needs to handle the case where key is PojoCacheable
> --------------------------------------------------------------------------------
>
>                 Key: JBCACHE-676
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-676
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> This is illustrated in org.jboss.cache.pojo.RecrusiveRefTest where we have map.put(valueId, valueObject) where both are PojoCacheable and valueId also embeded in valueObject. Therefore, if we treat valueId just as a Serializable, replication will cause the object reference split in valueObject (becuase in valueObject, valueId is treated by PojoCache).

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:32:49 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:32:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-110) PojoCache
 overriding toString or hashCode can trigger stack overflow
Message-ID: <14875796.1158553969717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-110?page=all ]

Ben Wang updated JBCACHE-110:
-----------------------------

       Affects: [Documentation (Ref Guide, User Guide, etc.)]
    Complexity: High

> PojoCache overriding toString or hashCode can trigger stack overflow
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-110
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-110
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion.
> Kabir has done it in:
> org.jboss.aspects.dbc.DesignByContractAspect

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:34:47 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:34:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-110) PojoCache
 overriding toString or hashCode can trigger stack overflow
Message-ID: <12298833.1158554087900.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-110?page=comments#action_12343446 ] 
            
Ben Wang commented on JBCACHE-110:
----------------------------------

Currently, I have used an annotation @Reentrant and the following declaration in jboss-aop.xml:

   <!-- This bind the jointpoint to specific in-memory operations. Currently in PojoUtil. -->
   <bind pointcut="execution(*
      @org.jboss.cache.pojo.annotation.Reentrant->toString())">
      <interceptor-ref name="Reentrant"/>
   </bind>

   <!-- Interceptor to perform Pojo level rollback -->
   <interceptor name="Reentrant" class="org.jboss.cache.pojo.interceptors.MethodReentrancyStopperInterceptor"
                scope="PER_INSTANCE"/>

The annotation currently applies only to List, Set, and Map impl now.

> PojoCache overriding toString or hashCode can trigger stack overflow
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-110
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-110
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion.
> Kabir has done it in:
> org.jboss.aspects.dbc.DesignByContractAspect

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:34:48 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:34:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-110) PojoCache
 overriding toString or hashCode can trigger stack overflow
Message-ID: <13949858.1158554088020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-110?page=all ]

Ben Wang resolved JBCACHE-110.
------------------------------

    Resolution: Done

> PojoCache overriding toString or hashCode can trigger stack overflow
> --------------------------------------------------------------------
>
>                 Key: JBCACHE-110
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-110
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>    Affects Versions: 1.2
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> In TreeCacheAOp, certain over-riding will trigger stack overflow. THis is becuase of the recursive field interecption that results. Solution is to detect the field recusion.
> Kabir has done it in:
> org.jboss.aspects.dbc.DesignByContractAspect

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 00:58:50 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 00:58:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <5083933.1158555530264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=all ]

Ben Wang updated JBCACHE-675:
-----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.)]
    Assignee: Ben Wang  (was: Scott Marlow)

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:00:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <6921269.1158555651524.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=comments#action_12343447 ] 
            
Ben Wang commented on JBCACHE-675:
----------------------------------

This test passes now in 2.0. Should also update the documentation.

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:00:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <3943952.1158555651635.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=all ]

Ben Wang resolved JBCACHE-675.
------------------------------

    Resolution: Done

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:00:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:00:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-675) Test case failure
 RecursiveRefTest
Message-ID: <11435950.1158555651770.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-675?page=comments#action_12343448 ] 
            
Ben Wang commented on JBCACHE-675:
----------------------------------

That is, in 2.0, we allow the Id key to be PojoCacheable as well as Serializable now.

> Test case failure RecursiveRefTest
> ----------------------------------
>
>                 Key: JBCACHE-675
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-675
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> The fix to require key as Serialiable cuases this test case:
> org.jboss.cache.pojo.RecrusiveRefTest to fail because in there it is put(valueId, valueObject) where valueId is a PojoCacheable object (but not Serializable). It is PojoCacheable becuase valueObject also uses valueId as the primary key.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:02:50 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:02:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-732) PojoCache
 introduces @NonTransient annotation
In-Reply-To: <16046460.1155187212288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16252560.1158555770796.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-732?page=all ]

Ben Wang updated JBCACHE-732:
-----------------------------

    Fix Version/s: PojoCache 2.1.0
                       (was: 2.0.0)

> PojoCache introduces @NonTransient annotation
> ---------------------------------------------
>
>                 Key: JBCACHE-732
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-732
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: PojoCache 2.1.0
>
>
> We need to introduce a @NonTransient annotation to override the transient modifier.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:04:50 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:04:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-163) Consolidate jboss
 related libraries
Message-ID: <22113600.1158555890985.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-163?page=all ]

Ben Wang updated JBCACHE-163:
-----------------------------

    Assignee: Manik Surtani  (was: Ben Wang)

Manik, I am assigning this to you now since you have been doing it already.

> Consolidate jboss related libraries
> -----------------------------------
>
>                 Key: JBCACHE-163
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-163
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Manik Surtani
>            Priority: Minor
>             Fix For: 2.0.0
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Currently the jboss dependent packaging in JBossCache is a bit scattered. We use the packaging from jboss-head but they are different the packaing, say, jboss-4.0. 
> For example, jboss head recently split jboss-j2ee.jar into jboss-j2ee and jboss-j2se.jar of which has no interests to us at all.
> Nonetheless, our dependency on jboss is very minimal now. So maybe we should think of consolidating all the jboss packaging into a single one? In theory, we should use the jboss packages from full release, like AS4.0.2.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 01:06:53 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 01:06:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-773) PojoCache to
 create an example for load-time option
Message-ID: <14816446.1158556013788.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to create an example for load-time option
---------------------------------------------------

                 Key: JBCACHE-773
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-773
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: 2.0.0


As titled.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:14:51 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 18 Sep 2006 02:14:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-774) PojoCache to use a
 RPC layer to transmit POJO events
Message-ID: <22632405.1158560091387.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to use a RPC layer to transmit POJO events
----------------------------------------------------

                 Key: JBCACHE-774
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-774
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Critical
             Fix For: PojoCache 2.1.0


Currently, the POJO events does not propagate to other nodes since there is no way to do that. We will need some specific RPC mechanism to that such that we can broadcast POJO attach, detach, and modification events. This will also help to remove the POJO cache interceptor on the remote node as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:44:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 02:44:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1043) introduce
 UserProfile and user metadata (storage mechanism agnostic)
Message-ID: <21948155.1158561890633.JavaMail.jira@cloud.prod.atl2.jboss.com>

introduce UserProfile and user metadata (storage mechanism agnostic)
--------------------------------------------------------------------

                 Key: JBPORTAL-1043
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1043
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- Each user entry (ldap or database table) can bring different set of user personal information. This makes the user profile
- In portal we have property names like: user.name, user.surname, user.email, user.phone and etc.
- Each UserModule implementation provide a mapping of properties to coresponding values in underlaying database or directory  
 (table columns or ldat entry attributes for eg.)
- Profile informations are accessed using API like:  
  user.getMetaData().getProfileMetaData().getProperty(User.NAME_PROPERTY);
  .getAllProperties().iterator()
- Currently this is handled by PropertyMap - keept as separate table in DB

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:48:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 02:48:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1044) test cases
 against LDAP implementation of identity modules
Message-ID: <32353706.1158562130447.JavaMail.jira@cloud.prod.atl2.jboss.com>

test cases against LDAP implementation of identity modules
----------------------------------------------------------

                 Key: JBPORTAL-1044
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1044
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- Testing in identity module should be implemented to perform implementation agnostic tests on different implementations of UserModule and RoleModule
- UserTestCase -> DBUserTestCase
- Introduce LDAPUserTestCase
- both reuse UserTest code so we can perform same tests on different implementations

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 02:54:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 02:54:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
Message-ID: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>

port OpenDS integration from JBoss AS testsuite to portal testsuite
-------------------------------------------------------------------

                 Key: JBPORTAL-1045
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Test
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 03:22:55 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Mon, 18 Sep 2006 03:22:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3663) JBoss Application
 Server Start Error
Message-ID: <21860359.1158564175530.JavaMail.jira@cloud.prod.atl2.jboss.com>

JBoss Application Server Start Error
------------------------------------

                 Key: JBAS-3663
                 URL: http://jira.jboss.com/jira/browse/JBAS-3663
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.1 SP1
         Environment: Windows 2000 Professional
            Reporter: madan srinivas
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.1 SP1


C:\jboss-4.0.1sp1\bin>run
===============================================================================
.
  JBoss Bootstrap Environment
.
  JBOSS_HOME: C:\jboss-4.0.1sp1\bin\\..
.
  JAVA: C:\Program Files\Java\jdk1.5.0_06\bin\java
.
  JAVA_OPTS:  -Dprogram.name=run.bat -Xms128m -Xmx512m
.
  CLASSPATH: C:\Program Files\Java\jdk1.5.0_06\lib\tools.jar;C:\jboss-4.0.1sp1\b
in\\run.jar
.
===============================================================================
.
10:04:24,284 INFO  [Server] Starting JBoss (MX MicroKernel)...
10:04:24,284 INFO  [Server] Release ID: JBoss [Zion] 4.0.1sp1 (build: CVSTag=JBo
ss_4_0_1_SP1 date=200502160314)
10:04:24,284 INFO  [Server] Home Dir: C:\jboss-4.0.1sp1
10:04:24,284 INFO  [Server] Home URL: file:/C:/jboss-4.0.1sp1/
10:04:24,284 INFO  [Server] Library URL: file:/C:/jboss-4.0.1sp1/lib/
10:04:24,284 INFO  [Server] Patch URL: null
10:04:24,284 INFO  [Server] Server Name: default
10:04:24,284 INFO  [Server] Server Home Dir: C:\jboss-4.0.1sp1\server\default
10:04:24,284 INFO  [Server] Server Home URL: file:/C:/jboss-4.0.1sp1/server/defa
ult/
10:04:24,284 INFO  [Server] Server Data Dir: C:\jboss-4.0.1sp1\server\default\da
ta
10:04:24,284 INFO  [Server] Server Temp Dir: C:\jboss-4.0.1sp1\server\default\tm
p
10:04:24,284 INFO  [Server] Server Config URL: file:/C:/jboss-4.0.1sp1/server/de
fault/conf/
10:04:24,284 INFO  [Server] Server Library URL: file:/C:/jboss-4.0.1sp1/server/d
efault/lib/
10:04:24,284 INFO  [Server] Root Deployment Filename: jboss-service.xml
10:04:24,299 INFO  [Server] Starting General Purpose Architecture (GPA)...
10:04:24,596 INFO  [ServerInfo] Java version: 1.5.0_06,Sun Microsystems Inc.
10:04:24,596 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_06-b05
,Sun Microsystems Inc.
10:04:24,596 INFO  [ServerInfo] OS-System: Windows 2000 5.0,x86
10:04:24,909 INFO  [Server] Core system initialized
10:04:26,831 ERROR [MainDeployer] could not create deployment: file:/C:/jboss-4.
0.1sp1/server/default/conf/jboss-service.xml
org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
.UndeclaredThrowableException)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:143)
        at org.jboss.system.ServiceController.install(ServiceController.java:200
)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy4.install(Unknown Source)
        at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:122)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:131)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
        at org.jboss.Main.boot(Main.java:162)
        at org.jboss.Main$1.run(Main.java:423)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.UndeclaredThrowableException
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
tor.java:153)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:118)
        ... 36 more
Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
ld/putstatic
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
        at java.lang.Class.getConstructor0(Class.java:2640)
        at java.lang.Class.getConstructor(Class.java:1629)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
1211)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
269)
        at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
327)
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
        ... 38 more
Failed to boot JBoss:
org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
.UndeclaredThrowableException)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:143)
        at org.jboss.system.ServiceController.install(ServiceController.java:200
)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy4.install(Unknown Source)
        at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
        at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
er.java:144)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
or.java:122)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
BeanOperationInterceptor.java:131)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
java:249)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
        at $Proxy5.deploy(Unknown Source)
        at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
        at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
        at org.jboss.Main.boot(Main.java:162)
        at org.jboss.Main$1.run(Main.java:423)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.reflect.UndeclaredThrowableException
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
        at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
tor.java:153)
        at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
:118)
        ... 36 more
Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
ld/putstatic
        at java.lang.Class.getDeclaredConstructors0(Native Method)
        at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
        at java.lang.Class.getConstructor0(Class.java:2640)
        at java.lang.Class.getConstructor(Class.java:1629)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
1211)
        at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
269)
        at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
327)
        at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
        ... 38 more
10:04:26,877 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages
Shutting down
10:04:26,877 INFO  [Server] Shutdown complete
Shutdown complete
Halting VM
Press any key to continue . . .

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:18:52 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 04:18:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3663) JBoss Application
 Server Start Error
In-Reply-To: <21860359.1158564175530.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8380437.1158567532088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3663?page=all ]

Dimitris Andreadis closed JBAS-3663.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.1 SP1)
       Resolution: Rejected

Something's wrong with your distribution, so validate the md5 signature of your .zip file.

> JBoss Application Server Start Error
> ------------------------------------
>
>                 Key: JBAS-3663
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3663
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.1 SP1
>         Environment: Windows 2000 Professional
>            Reporter: madan srinivas
>         Assigned To: Dimitris Andreadis
>
> C:\jboss-4.0.1sp1\bin>run
> ===============================================================================
> .
>   JBoss Bootstrap Environment
> .
>   JBOSS_HOME: C:\jboss-4.0.1sp1\bin\\..
> .
>   JAVA: C:\Program Files\Java\jdk1.5.0_06\bin\java
> .
>   JAVA_OPTS:  -Dprogram.name=run.bat -Xms128m -Xmx512m
> .
>   CLASSPATH: C:\Program Files\Java\jdk1.5.0_06\lib\tools.jar;C:\jboss-4.0.1sp1\b
> in\\run.jar
> .
> ===============================================================================
> .
> 10:04:24,284 INFO  [Server] Starting JBoss (MX MicroKernel)...
> 10:04:24,284 INFO  [Server] Release ID: JBoss [Zion] 4.0.1sp1 (build: CVSTag=JBo
> ss_4_0_1_SP1 date=200502160314)
> 10:04:24,284 INFO  [Server] Home Dir: C:\jboss-4.0.1sp1
> 10:04:24,284 INFO  [Server] Home URL: file:/C:/jboss-4.0.1sp1/
> 10:04:24,284 INFO  [Server] Library URL: file:/C:/jboss-4.0.1sp1/lib/
> 10:04:24,284 INFO  [Server] Patch URL: null
> 10:04:24,284 INFO  [Server] Server Name: default
> 10:04:24,284 INFO  [Server] Server Home Dir: C:\jboss-4.0.1sp1\server\default
> 10:04:24,284 INFO  [Server] Server Home URL: file:/C:/jboss-4.0.1sp1/server/defa
> ult/
> 10:04:24,284 INFO  [Server] Server Data Dir: C:\jboss-4.0.1sp1\server\default\da
> ta
> 10:04:24,284 INFO  [Server] Server Temp Dir: C:\jboss-4.0.1sp1\server\default\tm
> p
> 10:04:24,284 INFO  [Server] Server Config URL: file:/C:/jboss-4.0.1sp1/server/de
> fault/conf/
> 10:04:24,284 INFO  [Server] Server Library URL: file:/C:/jboss-4.0.1sp1/server/d
> efault/lib/
> 10:04:24,284 INFO  [Server] Root Deployment Filename: jboss-service.xml
> 10:04:24,299 INFO  [Server] Starting General Purpose Architecture (GPA)...
> 10:04:24,596 INFO  [ServerInfo] Java version: 1.5.0_06,Sun Microsystems Inc.
> 10:04:24,596 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.5.0_06-b05
> ,Sun Microsystems Inc.
> 10:04:24,596 INFO  [ServerInfo] OS-System: Windows 2000 5.0,x86
> 10:04:24,909 INFO  [Server] Core system initialized
> 10:04:26,831 ERROR [MainDeployer] could not create deployment: file:/C:/jboss-4.
> 0.1sp1/server/default/conf/jboss-service.xml
> org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
> .UndeclaredThrowableException)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :143)
>         at org.jboss.system.ServiceController.install(ServiceController.java:200
> )
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy4.install(Unknown Source)
>         at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:122)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:131)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
>         at org.jboss.Main.boot(Main.java:162)
>         at org.jboss.Main$1.run(Main.java:423)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.reflect.UndeclaredThrowableException
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
>         at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
> tor.java:153)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :118)
>         ... 36 more
> Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
> ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
> ld/putstatic
>         at java.lang.Class.getDeclaredConstructors0(Native Method)
>         at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
>         at java.lang.Class.getConstructor0(Class.java:2640)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 1211)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 269)
>         at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
> 327)
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
>         ... 38 more
> Failed to boot JBoss:
> org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect
> .UndeclaredThrowableException)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :143)
>         at org.jboss.system.ServiceController.install(ServiceController.java:200
> )
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy4.install(Unknown Source)
>         at org.jboss.deployment.SARDeployer.create(SARDeployer.java:208)
>         at org.jboss.deployment.MainDeployer.create(MainDeployer.java:918)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:774)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:722)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:144)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:122)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:131)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:413)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:310)
>         at org.jboss.Main.boot(Main.java:162)
>         at org.jboss.Main$1.run(Main.java:423)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.reflect.UndeclaredThrowableException
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:204)
>         at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigura
> tor.java:153)
>         at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java
> :118)
>         ... 36 more
> Caused by: java.lang.VerifyError: (class: org/jboss/invocation/pooled/server/Poo
> ledInvoker, method: loadCustomSocketFactories signature: ()V) Bad type in putfie
> ld/putstatic
>         at java.lang.Class.getDeclaredConstructors0(Native Method)
>         at java.lang.Class.privateGetDeclaredConstructors(Class.java:2328)
>         at java.lang.Class.getConstructor0(Class.java:2640)
>         at java.lang.Class.getConstructor(Class.java:1629)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 1211)
>         at org.jboss.mx.server.MBeanServerImpl.instantiate(MBeanServerImpl.java:
> 269)
>         at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:
> 327)
>         at org.jboss.system.ServiceCreator.install(ServiceCreator.java:125)
>         ... 38 more
> 10:04:26,877 INFO  [Server] JBoss SHUTDOWN: Undeploying all packages
> Shutting down
> 10:04:26,877 INFO  [Server] Shutdown complete
> Shutdown complete
> Halting VM
> Press any key to continue . . .

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:22:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:22:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1046) documentation
 for Ldap/Portal integration
Message-ID: <28666807.1158567770641.JavaMail.jira@cloud.prod.atl2.jboss.com>

documentation for Ldap/Portal integration
-----------------------------------------

                 Key: JBPORTAL-1046
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1046
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Create documentation of configuring Portal with LDAP. It needs to cover new implementation of identity modules in 2.6

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:32:52 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:32:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1047) Design ldap
 implementation for identity modules
Message-ID: <3389991.1158568372948.JavaMail.jira@cloud.prod.atl2.jboss.com>

Design ldap implementation for identity modules
-----------------------------------------------

                 Key: JBPORTAL-1047
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1047
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- Identity modules must handle both user/role retreival and creation 
- User and roles can be mapped in ldap directory tree in several different ways.
- There should be some flexible implementation desinged to handle different user/roles relations mapping strategies. (roles, group, both static and dynamic)
- This should also be opened for additional specific features for main LDAP implementations (RH, Sun, MSAD...)


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:34:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:34:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1048) Implementations
 of LDAP identity modules
Message-ID: <23673939.1158568490982.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implementations of LDAP identity modules
----------------------------------------

                 Key: JBPORTAL-1048
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1048
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Implementations of LDAP identity modules
like designed in: JBPORTAL-1047


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 04:36:51 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 04:36:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1049) LDAP integration
 in JBoss Portal
Message-ID: <11506068.1158568611696.JavaMail.jira@cloud.prod.atl2.jboss.com>

LDAP integration in JBoss Portal
--------------------------------

                 Key: JBPORTAL-1049
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1049
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Identity
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


Grouping task for all ldap issues in portal for 2.6

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:06:51 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Mon, 18 Sep 2006 05:06:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3664) Deploying EJB3.0
	entity bean
Message-ID: <4578824.1158570411764.JavaMail.jira@cloud.prod.atl2.jboss.com>

Deploying EJB3.0 entity bean
----------------------------

                 Key: JBAS-3664
                 URL: http://jira.jboss.com/jira/browse/JBAS-3664
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.1 SP1
         Environment: Windows 2000 Professional
            Reporter: madan srinivas
         Assigned To: Dimitris Andreadis


Hi,
I am deploying EJB3.0 Entity bean on JBoss 4.0.1sp1.
I am having ejb-jar.xml and persistence.xml in my META-INF and 
Entity bean is not using any Remote Interface; as another Stateless SessionBean is instantiating the POJO Entitbean FileDetailsServiceBO and using EntityManager for persistence.

I get following error , Pls help.

14:29:31,163 WARN  [verifier] EJB spec violation:
Bean   : FileDetailsServiceBO
Section: 10.6.2
Warning: The entity bean's class must implement, directly or indirectly, the javax.ejb.EntityBean interface.

14:29:31,163 WARN  [verifier] EJB spec violation:
Bean   : FileDetailsServiceBO
Section: 10.6.2
Warning: The entity bean class must be defined as public and abstract.

14:29:31,163 WARN  [verifier] EJB spec violation:
Bean   : FileDetailsServiceBO
Section: 10.6.1
Warning: The Bean Provider must provide a remote interface and a remote home int
erface or a local interface and a local home interface for the bean.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:14:58 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 05:14:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3664) Deploying EJB3.0
	entity bean
In-Reply-To: <4578824.1158570411764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20026409.1158570898034.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3664?page=all ]

Dimitris Andreadis closed JBAS-3664.
------------------------------------

    Resolution: Rejected

Please use the forums to ask for help, JIRA is not the right place.

And use the installer of one of the latest jboss releases to get an ejb3 enabled configuration.

> Deploying EJB3.0 entity bean
> ----------------------------
>
>                 Key: JBAS-3664
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3664
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.1 SP1
>         Environment: Windows 2000 Professional
>            Reporter: madan srinivas
>         Assigned To: Dimitris Andreadis
>
> Hi,
> I am deploying EJB3.0 Entity bean on JBoss 4.0.1sp1.
> I am having ejb-jar.xml and persistence.xml in my META-INF and 
> Entity bean is not using any Remote Interface; as another Stateless SessionBean is instantiating the POJO Entitbean FileDetailsServiceBO and using EntityManager for persistence.
> I get following error , Pls help.
> 14:29:31,163 WARN  [verifier] EJB spec violation:
> Bean   : FileDetailsServiceBO
> Section: 10.6.2
> Warning: The entity bean's class must implement, directly or indirectly, the javax.ejb.EntityBean interface.
> 14:29:31,163 WARN  [verifier] EJB spec violation:
> Bean   : FileDetailsServiceBO
> Section: 10.6.2
> Warning: The entity bean class must be defined as public and abstract.
> 14:29:31,163 WARN  [verifier] EJB spec violation:
> Bean   : FileDetailsServiceBO
> Section: 10.6.1
> Warning: The Bean Provider must provide a remote interface and a remote home int
> erface or a local interface and a local home interface for the bean.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:16:59 2006
From: jira-events at jboss.com (Maurice Zeijen (JIRA))
Date: Mon, 18 Sep 2006 05:16:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10453667.1158571019100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=comments#action_12343455 ] 
            
Maurice Zeijen commented on JBSEAM-347:
---------------------------------------

I discoverd that this problem has to do with myFaces. If you make sure that myFaces doesn't get initialized (via web.xml or the .tld) then this exception doesn't happen.

> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:49:57 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Mon, 18 Sep 2006 05:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-148) Include
 Tomcat's
 SavedRequest object into the replication process in a Jboss-Tomcat
 clustered environment to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17498840.1158572997453.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=comments#action_12343457 ] 
            
Alberto Rodriguez commented on JBCLUSTER-148:
---------------------------------------------

An issue at tomcat's issue traker was opened, the discussion can be followed here: http://issues.apache.org/bugzilla/show_bug.cgi?id=40531

> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:52:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 05:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3346)
 org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase
 causes 1.5 BEA JVM to core dump
Message-ID: <27420000.1158573121064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3346?page=all ]

Dimitris Andreadis reassigned JBAS-3346:
----------------------------------------

    Assignee: Dimitris Andreadis

> org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase causes 1.5 BEA JVM to core dump
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3346
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: RHEL 4, x86_64 processor, BEA 1,5 JDK
>            Reporter: Len DiMaggio
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> With this JDK:
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> BEA JRockit(R) (build dra-45238-20050523-2021-linux-x86_64, R25.2.0-28)
> And this test from the JBoss 4.0.4/GA test suite (download from jboss.com) - the test causes a code dump when it executes line 62.
>      1	/*
>      2	* JBoss, Home of Professional Open Source
>      3	* Copyright 2005, JBoss Inc., and individual contributors as indicated
>      4	* by the @authors tag. See the copyright.txt in the distribution for a
>      5	* full listing of individual contributors.
>      6	*
>      7	* This is free software; you can redistribute it and/or modify it
>      8	* under the terms of the GNU Lesser General Public License as
>      9	* published by the Free Software Foundation; either version 2.1 of
>     10	* the License, or (at your option) any later version.
>     11	*
>     12	* This software is distributed in the hope that it will be useful,
>     13	* but WITHOUT ANY WARRANTY; without even the implied warranty of
>     14	* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>     15	* Lesser General Public License for more details.
>     16	*
>     17	* You should have received a copy of the GNU Lesser General Public
>     18	* License along with this software; if not, write to the Free
>     19	* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>     20	* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>     21	*/
>     22	package org.jboss.test.cmp2.batchcascadedelete.test;
>     23	
>     24	import org.jboss.test.JBossTestCase;
>     25	import org.jboss.test.cmp2.batchcascadedelete.ejb.Child;
>     26	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildHome;
>     27	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildUtil;
>     28	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildHome;
>     29	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildUtil;
>     30	import org.jboss.test.cmp2.batchcascadedelete.ejb.Parent;
>     31	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentHome;
>     32	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentUtil;
>     33	import junit.framework.Test;
>     34	
>     35	/**
>     36	 * @author <a href="mailto:alex at jboss.org">Alexey Loubyansky</a>
>     37	 * @version <tt>$Revision: 1.1.2.2 $</tt>
>     38	 */
>     39	public class BatchCascadeDeleteUnitTestCase
>     40	   extends JBossTestCase
>     41	{
>     42	   /**
>     43	    * Constructor for the JBossTestCase object
>     44	    *
>     45	    * @param name Test case name
>     46	    */
>     47	   public BatchCascadeDeleteUnitTestCase(String name)
>     48	   {
>     49	      super(name);
>     50	   }
>     51	
>     52	   public static Test suite() throws Exception
>     53	   {
>     54	      return JBossTestCase.getDeploySetup(BatchCascadeDeleteUnitTestCase.class, "cmp2-batchcascadedelete.jar");
>     55	   }
>     56	
>     57	   public void testCase4540() throws Exception
>     58	   {
>     59	      ParentHome parentHome = ParentUtil.getHome();
>     60	      Parent parent = parentHome.create("parent");
>     61	
>     62	      ChildHome childHome = ChildUtil.getHome();
>     63	      Child child = childHome.create( parent, "child");
>     64	
>     65	      GrandchildHome grandchildHome = GrandchildUtil.getHome();
>     66	
>     67	      // If you comment out the next line, then the call to child.remove() works fine.
>     68	      grandchildHome.create(child.getId(), "grandchild");
>     69	
>     70	      this is the test for non-null foreign key
>     71	      child.remove();
>     72	   }
>     73	}
> Here's the dump file:
> Linux x86_64-4as.lab.boston.redhat.com 2.6.9-39.ELsmp #1 SMP Thu Jun 1 18:01:55 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> ===== BEGIN DUMP =============================================================
> JRockit dump produced after 0 days, 00:29:38 on Wed Jun 21 13:56:36 2006
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Error Message: Illegal memory access. [54]
> Signal info  : si_signo=12, si_code=-6
> Version      : BEA JRockit(R) R25.2.0-28 dra-45238-20050523-2021-linux-x86_64
> GC           : System optimized over throughput (initial strategy singleparpar)
>              : GC strategy for GC 4 was genparpar
>              : GC strategy for GC 5 was singleparpar
>              : GC strategy for GC 6 was genparpar
>              : GC strategy for GC 7 was singleparpar
>              : GC strategy for GC 8 was genparpar
>              : mmHeap->data = 0x20000000, mmHeap->top = 0x28000000
>              : mmStartCompaction = 0x21800000, mmEndCompaction = 0x22000000
> CPU          : Intel Pentium 4 SSE SSE2 NetBurst EM64T
> Number CPUs  : 2
> Tot Phys Mem : 4120244224
> OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 4 Beta)
> Linux version 2.6.9-39.ELsmp (bhcompile at hs20-bc1-6.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Thu Jun 1 18:01:55 EDT 2006
> State        : JVM is running (Main thread has finished)
> Command Line : -Djrockit.launcher.type=jrockit.shipment -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/lib/endorsed org.jboss.Main -c all
> Environment  : JAVA_HOME=(null), java.home=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre, java.class.path=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar, java.library.path=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/../lib/amd64
> C Heap       : Good; no memory allocations have failed
> Registers (from context struct at 0x40e899f8/0x40e89a70):
> RAX = ffffffff00000010  RBX = 00000000f7bc5de8
> RCX = 00000000f7bc5df8  RDX = 00000000ffcb1bf3
> R8  = 000000000002feeb  R9  = 000000009090feeb
> R10 = 0000002a9b7aeed0  R11 = 0000002a9577893c
> R12 = 0000000040e89e58  R13 = 0000000000000001
> R14 = 0000000000000001  R15 = 0000002a9b7aed08
> RSI = 0000000020c8bb78  RDI = 00000000220b1108
> RSP = 0000000040e89eb0  RIP = 00000001009ccec8
> RBP = 00000000220b1108  RFL = 00000206
> CS = 0000 GS = 0000 FS = 0000
> Stack:
> 0000000040e89eb0: 0000000021ff0238 00000001009ccbb5 00000000220d6b28 0000000020c81130 0000000022078920 0000000021ff0238 
> 0000000040e89ee0: 0000000100000a22 0000000003c3d730 00000000220d6b40 0000000020c8bb48 0000000022078920 0000000021ff0238 
> 0000000040e89f10: 00000001009ca128 00000001009c9fdf 0000000022078920 0000000020c70cb0 00000000220b22a8 00000000220924a8 
> 0000000040e89f40: 0000000020c8bb48 0000000021ff0238 0000000022078920 0000000020c6ed78 00000001009c9c23 0000000020c6ee40 
> 0000000040e89f70: 0000000100000a45 000000000000001c 0000000021ff0238 0000000020c6ed78 0000000022078920 0000000021ff0238 
> 0000000040e89fa0: 00000001009c9b55 0000000020c137d8 00000001009c8e0f 0000000000000000 0000000022078920 0000000020b0b3b8 
> 0000000040e89fd0: 0000000021ff0238 0000000020c8b568 0000000000000000 0000000021ff0238 0000000020c137d8 0000000021ff0238 
> 0000000040e8a000: 0000000021ff0238 00000001009c8cb5 0000000020c0f3d8 00000001009c8bd4 0000000020c10a90 0000000003c064b0 
> 0000000040e8a030: 0000000021ff0238 0000000020c0f3d8 00000001009c8a8f 0000000003c057f0 0000000020a5ddb0 00000000220924a8 
> 0000000040e8a060: 00000001009c8296 0000000000000001 0000002a9b7aed08 000000010000090f 00000000005d7cd0 0000002a9b7aeed0 
> 0000000040e8a090: 00000000a6bf41f8 0000000020c0dca8 0000000021ff0238 0000000000000000 0000000020a5ddb0 0000000003bffb80 
> 0000000040e8a0c0: 0000000021ff0238 0000000000000000 0000000020a5ddb0 00000000220924a8 00000001009c7386 0000000020a5ddb0 
> 0000000040e8a0f0: 03c028209b7aed08 0000002a9b7aeed8 0000000020c0dca8 0000000000000000 00000000220924a8 0000000021ff0238 
> 0000000040e8a120: 0000000000000000 00000000220924a8 000000000000012c 0000002a9b7aeed0 0000000100000000 000000010002bdf0 
> 0000000040e8a150: 0000000020c08a38 0000000020a5ddb0 0000000100000a22 0000000003c00cf8 0000000000000001 00000000274b8c38 
> 0000000040e8a180: 0000000020c08a38 0000000021ff0238 00000001009c6da7 0000000100000a45 0000000020c0dca8 0000000021ff0238 
> 0000000040e8a1b0: 0000000000000000 0000000000000000 0000000021ff0238 00000001009c62a0 0000000021ff0238 0000000020c07368 
> 0000000040e8a1e0: 00000001009c612a 00000000005d7c90 0000000020c07368 0000000021ff0238 0000000021103b10 0000000000000000 
> 0000000040e8a210: 0000000021ff0238 0000000100000a45 000000000000001c 0000002a969f1010 0000000003bf6978 0000000020c05d48 
> 0000000040e8a240: 0000000021ff0238 00000001009c5b5f 0000000021ff0238 0000000000000000 0000000021ff4240 0000000020c05d48 
> 0000000040e8a270: 0000000021ff0238 0000000020b0b3b8 0000000021ff0238 00000001009c58b4 00000000210fb030 0000000040e8a3e0 
> 0000000040e8a2a0: 0000000020a5ddb0 00000001009c4f23 00000000269f9f90 0000000020b0b3b8 0000000021ff0238 0000000021033388 
> 0000000040e8a2d0: 0000010bf7bc5c80 00000000210fb030 0000002a00000001 0000000000000000 0000002a9b7aed08 0000002a956ad0b1 
> 0000000040e8a300: 000000000000029c 0000000002645f21 0000002a9b7aeec0 0000000040e8a598 0000000040e8a3e0 0000000040e8a560 
> 0000000040e8a330: 0000000100030068 0000000040e8a4f8 0000000040e8a3e0 00000001009c4b10 0000002a9b7aeb20 0000002a9b7aed08 
> 0000000040e8a360: 0000000000000001 0000000000000001 0000000040e8a3e0 0000002a9b7aed08 000000000064ca60 0000002a9560787a 
> 0000000040e8a390: 0000000000000002 0000002a956d3107 0000000103bb9370 000000000056aaa8 0000000040e8a500 0000002a9b7aee48 
> 0000000040e8a3c0: 0000002a9b7b3b00 0000002a956aca24 0000000003bb9370 0000000002643f80 0000002a9b7aee48 0000002a9b7aeec0 
> 0000000040e8a3f0: 0000000000000000 0000000100000000 0000000100000001 0000002a9b7aed28 0000000003bb9370 0000002a9b7aed08 
> 0000000040e8a420: 000000000056aaa8 0000000100000007 0000000200000001 0000000200000000 0000002a00000000 0000002a956c3228 
> 0000000040e8a450: 03bc261800000000 0000000002643f80 0000002a9b7aed08 0000002a9b7b3b00 0000002a9b7aee48 0000002a956c36f0 
> 0000000040e8a480: 0000000000000000 0000002a956c337c 0000002a956c36f0 0000000040e8a4f8 0000000040e8a500 0000000002643f80 
> 0000000040e8a4b0: 0000000000000001 0000002a9b7aee48 0000000000000000 0000002a9b7aed08 0000000002643f80 0000002a956c37c9 
> 0000000040e8a4e0: 011f3cc000000000 0000000040e8a4f8 000000010003af7a 0000002a9b7aeec8 0000000040e8a598 0000002a9b7aed08 
> 0000000040e8a510: 00000001001ecc8b 0000002a9b7aee58 0000002a9b7aeb20 0000000040e8a560 0000000000000001 0000000000000001 
> 0000000040e8a540: 0000002a9b7aed08 0000002a956cc14a 0000002a9b7aee48 000000010003c1e0 0000000000688b30 0000002a9b7aee48 
> 0000000040e8a570: 000000002192dec8 000000010003bfa7 0000000020b0b3b8 0000000021ff6d58 000000010003bea6 0000000021ff6be8 
> 0000000040e8a5a0: 0000000021ff6d58 0000000020b0b3b8 0000000021ff6be8 0000000100000001 0000000020b0b3b8 0000000020b0b3b8 
> 0000000040e8a5d0: 0000000021ff6be8 000000010005db3e 0000000021ff6be8 0000000021ff6d58 0000000020b0b3b8 0000000021ff6d98 
> 0000000040e8a600: 000000010003bd09 0000000021ff6be8 0000000021ff6be8 0000000021ff6be8 0000000020fa8d58 000000010003b2d5 
> 0000000040e8a630: 0000000021ff6be8 0000000020b0b3b8 0000000001939c68 0000000100003945 00000000200a1118 0000000025179958 
> 0000000040e8a660: 0000000000000001 000000000193de20 0000000021ff6c80 0000000020fa8d58 000000010023c5c8 0000000021ff6be8 
> 0000000040e8a690: 00000000ffffffff 0000000021ff6d10 0000000020ffd028 0000000021ff6c80 0000000020fa8d58 0000000020b0b3b8 
> Code:
> 00000001009ccdc8: 894890ff672533e8 c3d2f8252c8b48f3 0001025188b84803 ff6362c8e8000000 0e7ee82824748948 482824748b48ff67 
> 00000001009ccdf8: 00002a9b7ca2b8bf 26048b273c8b4800 7c8b48ff670fa3e8 0e16e826048b0824 0f0ee826048bff69 ee8948f78948ff67 
> 00000001009cce28: 90004d8b241c8948 50b848ff6bef21e8 9000000000010531 df8948ff63626be8 25048b4864f38948 28468948000000d8 
> 00000001009cce58: de8948ff647717e8 894890ff67249be8 ede81024748b48f3 85e8de8948ff6364 cccccccc90ff6724 8bfe8948f38948cf 
> 00000001009cce88: ffffffe0b848260c 480114ffffffffff 67b8c189c389de89 c1c889e9f7666666 89c2011fe8c104fa c82928c96bd189d8 
> 00000001009cceb8: 08768b48137fc085 1776084639d8f748 48c35b10c6748b48 127608463908768b 48c35b10c6748b48 000001009ccec6b8 
> 00000001009ccee8: 009cced6b848f400 ccccccf400000001 cccccccccccccccc 8b4840ec83485553 854820408b483846 4800000213840fc0 
> 00000001009ccf18: 4de838768b48f389 05e8f58948000002 8948c18948ff75bb 314830244c8948d8 44894838708b48db 0c8b20768b480824 
> 00000001009ccf48: e8ffff43e1e89026 24548b48ff63622c 89480824448b4830 244c8948ee8948f1 0093e910768b4828 8948304e8b480000 
> 00000001009ccf78: 8948d58948382474 8948cd2948302454 0c8b0824448948c6 48ffe4d635e89020 d53948d88948c289 480774c08548737c 
> 00000001009ccfa8: b84826eb38245c8b 00000000011df298 f38948ff6360f3e8 5c8948ff66b3dbe8 481024448b481024 48df894838245c8b 
> Loaded modules:
> (* denotes the module causing the exception)
> 0x400000-0x411037  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/bin/java
> 0x3a5dc00000-0x3a5dc0eff9  /lib64/tls/libpthread.so.0
> 0x3a5d400000-0x3a5d48459b  /lib64/tls/libm.so.6
> 0x3a5cf00000-0x3a5cf01c73  /lib64/libdl.so.2
> 0x3a5d100000-0x3a5d22ac59  /lib64/tls/libc.so.6
> 0x3a5cd00000-0x3a5cd1434f  /lib64/ld-linux-x86-64.so.2
> 0x2a95588000-0x2a957a660f  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit/libjvm.so
> 0x2a959e3000-0x2a959ecf13  /lib64/libnss_files.so.2
> 0x2a96c6f000-0x2a96c93473  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libjava.so
> 0x2a96d99000-0x2a96da5627  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libverify.so
> 0x3a62e00000-0x3a62e134eb  /lib64/libnsl.so.1
> 0x2a99d9f000-0x2a99db3fcf  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libnet.so
> 0x2a99eb6000-0x2a99ebed33  /lib64/libnss_nis.so.2
> 0x2a99fc0000-0x2a99fc38a3  /lib64/libnss_dns.so.2
> 0x3a5e200000-0x3a5e210d9b  /lib64/libresolv.so.2
> 0x2a9b5c8000-0x2a9b5c897b  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/librmi.so
> "RMI TCP Connection(4)-192.168.7" id=149 idx=0xc8 tid=1088993632 lastJavaFrame=(nil)
> Thread Stack Trace:
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Extended, platform specific info:
> libc release: 2.3.4-stable
> Elf headers:
> libc       ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5d11c4a0 PHOFF: 0x40 SHOFF: 0x13d5a8 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 69 STIDX: 66
> libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5dc05620 PHOFF: 0x40 SHOFF: 0x12980 EF: 0x0 HS: 64 PS: 56 PHN; 9 SS: 64 SHN: 38 STIDX: 35
> libjvm     ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x36c80 PHOFF: 0x40 SHOFF: 0x3106f0 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
> ===== END DUMP ===============================================================

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 05:54:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 05:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2086) Transform some
 Managed Objects in SMO
Message-ID: <30281155.1158573241292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2086?page=all ]

Dimitris Andreadis updated JBAS-2086:
-------------------------------------

       Issue Type: Feature Request  (was: Patch)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

we need to properly evaluate this change

> Transform some Managed Objects in SMO
> -------------------------------------
>
>                 Key: JBAS-2086
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2086
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final,  JBossAS-4.0.3RC1
>         Environment: jmx, twiddle
>            Reporter: Fabiano C. de Oliveira
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: management.patch
>
>
> Make managed objects that inherits from J2EEDeployedObject a SMO. The exception is WebModule and ServiceModule for a while. 
> To prevent copy&paste pattern and duplicate code the StateManagement code was moved to ManagedObject class. Instead initialize states using ServiceMBean ServiceContext was used(Adrian advice). This form MBeans tha not implement ServiceMBean not launch a exception. Tested using jmx-console and trace logs only.
> Some managed object still are not a SMO, but it is not difficult to change this.
> Suggestions always appreciated.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:05:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2008) web console
 statistics view does not show properly in Firefox
Message-ID: <1363669.1158573901291.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2008?page=all ]

Dimitris Andreadis updated JBAS-2008:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> web console statistics view does not show properly in Firefox
> -------------------------------------------------------------
>
>                 Key: JBAS-2008
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2008
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Firefox
>            Reporter: Kevin Barfield
>            Priority: Minor
>
> The statistics view in the web console has a box though it when viewed through the Firefox browser.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:09:55 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:09:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1979) Wrong resolve
 LinkRef when dereference partial result
Message-ID: <6689871.1158574195935.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1979?page=all ]

Dimitris Andreadis updated JBAS-1979:
-------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)

> Wrong resolve LinkRef  when dereference partial result
> ------------------------------------------------------
>
>                 Key: JBAS-1979
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1979
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-3.2.6 Final
>         Environment: Windows 2000
>            Reporter: Boris Stepchenko
>            Priority: Minor
>
> When dereference LinkRef  in partial result used "new InitialContex()", but not "new InitialContex(refEnv)"
> So if I bind LinkRef  to url "dir1/dir2/link"
> I have different result in 2 next code
> 1.
> Contexct ctx=new InitialContext(refEnv);
> Object obj=((Context)ctx.lookup("dir1/dir2/link")).lookup("value");
> and 2.
> Contexct ctx=new InitialContext(refEnv);
> Object obj=ctx.lookup("dir1/dir2/link/value");

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:09:56 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <973004.1158574196094.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Who's maintaining the webconsole?

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:09:56 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:09:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <30449371.1158574196215.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Comment: was deleted

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:16:54 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:16:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1703) inspectMBean.jsp
 throws AccessControlException
Message-ID: <10665721.1158574614922.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1703?page=all ]

Dimitris Andreadis updated JBAS-1703:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> inspectMBean.jsp throws AccessControlException
> ----------------------------------------------
>
>                 Key: JBAS-1703
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1703
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions:  JBossAS-4.0.2RC1
>         Environment: JBoss Version 4.0.2RC1 
>            Reporter: Roland R?z
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The inspectMBean.jsp page throws a AccessControlException (javax.management.MBeanServerPermission is
> missing) although the codesource from where the JSP servlet is loaded (I use precompiled JSPs) has those
> permission.
> This is the code section where the AccessControlException is thrown
>   for(int a = 0; a < attributeInfo.length; a ++)
>    {
>       final MBeanAttributeInfo attrInfo = attributeInfo[a];
>       String attrName = attrInfo.getName();
>       String attrType = attrInfo.getType();
>       AttrResultInfo attrResult = Server.getMBeanAttributeResultInfo(objectNameString, attrInfo);
> ...
> You should use AccessController.doPrivileged to execute the code 
> AttrResultInfo attrResult = Server.getMBeanAttributeResultInfo(objectNameString, attrInfo);
> Regards

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:18:57 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1608) Configuration (RW)
 attribute on JMX-Console breaks for jboss:service=Mail MBean
Message-ID: <13298475.1158574737137.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1608?page=all ]

Dimitris Andreadis updated JBAS-1608:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Defer minor issues for now, unless Amit you want to provide a patch.

> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-1608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1608
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.0 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,  JBossAS-4.0.2RC1
>         Environment: Nothing specific
>            Reporter: Amit Bhayani
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz at nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:18:57 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 18 Sep 2006 06:18:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-499) Rule not rendering
 activation group correctly
Message-ID: <18329106.1158574737302.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rule not rendering activation group correctly
---------------------------------------------

                 Key: JBRULES-499
                 URL: http://jira.jboss.com/jira/browse/JBRULES-499
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Decision tables
    Affects Versions: 3.0.4
            Reporter: Michael Neale
         Assigned To: Michael Neale




-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:20:53 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:20:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15228601.1158574853987.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3651?page=all ]

Dimitris Andreadis updated JBAS-3651:
-------------------------------------

    Assignee: Dimitris Andreadis
    Priority: Critical  (was: Major)

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:20:54 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:20:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3611) Get the
 jboss-4.0-testsuite-sun-1.5 passing
In-Reply-To: <20914255.1157137303968.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3148282.1158574854119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3611?page=all ]

Dimitris Andreadis reassigned JBAS-3611:
----------------------------------------

    Assignee: Dimitris Andreadis

> Get the jboss-4.0-testsuite-sun-1.5 passing
> -------------------------------------------
>
>                 Key: JBAS-3611
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3611
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task for sun jdk1.5 test run failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:22:53 2006
From: jira-events at jboss.com (Amit Bhayani (JIRA))
Date: Mon, 18 Sep 2006 06:22:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-1608) Configuration (RW)
 attribute on JMX-Console breaks for jboss:service=Mail MBean
Message-ID: <4453709.1158574973706.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1608?page=all ]

Amit Bhayani reassigned JBAS-1608:
----------------------------------

    Assignee: Amit Bhayani

> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-1608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1608
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.0 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,  JBossAS-4.0.2RC1
>         Environment: Nothing specific
>            Reporter: Amit Bhayani
>         Assigned To: Amit Bhayani
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz at nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:22:53 2006
From: jira-events at jboss.com (Amit Bhayani (JIRA))
Date: Mon, 18 Sep 2006 06:22:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1608) Configuration (RW)
 attribute on JMX-Console breaks for jboss:service=Mail MBean
Message-ID: <3231291.1158574973878.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1608?page=comments#action_12343461 ] 
            
Amit Bhayani commented on JBAS-1608:
------------------------------------

Will take a look at this latter. 

> Configuration (RW) attribute on JMX-Console breaks for jboss:service=Mail MBean
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-1608
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1608
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.0 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final,  JBossAS-4.0.2RC1
>         Environment: Nothing specific
>            Reporter: Amit Bhayani
>         Assigned To: Amit Bhayani
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The Configuration (RW) attribute of jboss:service=Mail MBean breaks (doesn't display the whole property but while setting it works fine) when encounters " (double inverted comma).
> For example set the following in Configuration (RW) attribute <configuration><property name="mail.from" value="xyz at nosuchhost.nosuchdomain.com"/></configuration> and apply changes. Now on Configuration textbox you can see <configuration><property name= only.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:24:53 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:24:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3598) Get the 4.0.5.GA
 testsuite-1.4 (JRockit) passing
In-Reply-To: <31303322.1157127343880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18852490.1158575093552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3598?page=all ]

Dimitris Andreadis reassigned JBAS-3598:
----------------------------------------

    Assignee: Dimitris Andreadis

> 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
>         Assigned To: 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

        


From jira-events at jboss.com  Mon Sep 18 06:24:53 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:24:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.5.GA
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25982821.1158575093671.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis reassigned JBAS-3437:
----------------------------------------

    Assignee: Dimitris Andreadis

> Get the 3.2-compatibility tests passing for 4.0.5.GA
> ----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2037) Bug in the JBoss
	HTML adaptor.
Message-ID: <15858138.1158576421481.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2037?page=all ]

Dimitris Andreadis updated JBAS-2037:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Bug in the JBoss HTML adaptor.
> ------------------------------
>
>                 Key: JBAS-2037
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-3.2.5 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1,  JBossAS-4.0.3RC1
>            Reporter: jean deruelle
>             Fix For: JBossAS-4.0.6.CR1
>
>
> "The set of characters in a value is also limited. If
> special characters may occur, it is recommended that the
> value be quoted, using ObjectName.quote. If the value for a
> given key is sometimes quoted, then it should always be
> quoted. By default, if a value is a string (rather than a
> number, say), then it should be quoted unless you are sure
> that it will never contain special characters." quoted from
> java management best practices (see
> http://java.sun.com/products/JavaManagement/best-practices.html#mozTocId654884
> in section ObjectNameSyntax)
> When a JMX value is quoted, it causes problems to invoke methods through thr Jboss jmx web console :
> So my feeling is that the problem comes from the jboss jmx
> console jsp pages.
> The thing is that the quotes in the jmx object name are not
> encoded to the html format in the jsp pages and so the first
> opening quote is interpreted as the final quote of the html
> field.
> Here is a quick fix for Jboss-3.2.6 :
> Add the following lines to
> %JBOSS_HOME%\server\all\deploy\jmx-console.war\inspectMBean.jsp
> after line 141
> <%objectNameString=objectNameString.replaceAll("\"","&quot;");
> //objectNameString=URLEncoder.encode(objectNameString);%>
> It was a quick fix to fit my needs but the
> line should really be the one commented but in that case the
> HtmlAdaptorServlet from Jboss cannot handle it correctly
> because it doesn't do a URLDecoder.decode of the
> objectNameString stored in the request parameter called "name".
> But I might be wrong here in saying that it comes from
> jboss, maybe I missed something along the way. 
> Can someone confirm this bug or help me out there ?
> Thx
> Best regards
> Jean

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:49:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Mon, 18 Sep 2006 06:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3187) Improve web-console
	logging
Message-ID: <15190310.1158576541222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3187?page=all ]

Darran Lofthouse updated JBAS-3187:
-----------------------------------

    Component/s: Web Console
                     (was: Management services)

> Improve web-console logging
> ---------------------------
>
>                 Key: JBAS-3187
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3187
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console application has been implemented so that it is not strictly dependent on the components that it makes available in the tree.
> On initialisation if there are any errors initialising the viewer for any components in the tree view an error is output but the component is not added to the tree and the remaining components are initialised correctly.  The web-console continues to work correctly for the components that were correctly initialised with no negative effects from the components that failed to initialise.
> The web-console does not make use of Log4j at the moment.
> The web-console should be updated to use Log4j (Being careful with classes sent to the applet) and the initialisation failures should be logged at a low  level (either DEBUG or even TRACE).  This will allow the web-console to be installed in more configurations without as many dependencies.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:51:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1748) hot deploying JMX
 invoker service fails
Message-ID: <11418960.1158576661750.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1748?page=all ]

Dimitris Andreadis updated JBAS-1748:
-------------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1
                       (was: JBossAS-4.0.5.GA)

> hot deploying JMX invoker service fails
> ---------------------------------------
>
>                 Key: JBAS-1748
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1748
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Norman Richards
>         Assigned To: Vicky Kak
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.CR1
>
>
> jmx-invoker-service.xml cannot be hot deployed.  Trying to hot deploy it causes a failure when redeploying the web console.  After this failure, I the JMX invoker cannot be contacted.  Here's the resulting web console error:
> 22:49:04,904 ERROR [WebModule] Starting failed jboss.web.deployment:id=-1500951031,war=web-console.war
> java.lang.NullPointerException
>         at org.jboss.web.WebModule.startModule(WebModule.java:67)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:272)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:222)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:911)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:416)
>         at org.jboss.system.ServiceController.start(ServiceController.java:438)
>         at org.jboss.system.ServiceController.start(ServiceController.java:438)
>         at org.jboss.system.ServiceController.start(ServiceController.java:438)
>         at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:273)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:964)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:775)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:738)
>         at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:121)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:177)
>         at $Proxy8.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:325)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:483)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:204)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:215)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:194)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:51:02 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:51:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2477) Exception in
 web-console j2ee domain after undeploy of application
Message-ID: <13220918.1158576662308.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2477?page=all ]

Dimitris Andreadis updated JBAS-2477:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse

> Exception in web-console j2ee domain after undeploy of application
> ------------------------------------------------------------------
>
>                 Key: JBAS-2477
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2477
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Both Linux and Windows
>            Reporter: Lennart Petersson
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Had listed all apps in web-console j2ee domains. Then undeployed one app. Then list again in web-console ---> exception below.
> 10:31:54,896 INFO  [TomcatDeployer] undeploy, ctxPath=/crimeportal, warUrl=.../tmp/deploy/tmp65013crimeportal.war/
> 10:31:54,914 INFO  [EJBDeployer] Undeploying: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/CrimePortalBeans.jar
> 10:31:55,162 INFO  [ProxyFactory] Unbind EJB Home 'SicilianLaundry' from jndi 'SicilianLaundry'
> 10:31:55,172 INFO  [EjbModule] Undeployed SicilianLaundry
> 10:31:55,173 INFO  [ProxyFactory] Unbind EJB Home 'ShanghaiLaundry' from jndi 'ShanghaiLaundry'
> 10:31:55,173 INFO  [EjbModule] Undeployed ShanghaiLaundry
> 10:31:55,190 INFO  [EARDeployer] Undeploying J2EE application, destroy step: file:/home/lenp/sources/jboss-4.0.3SP1/build/output/jboss-4.0.3SP1/server/lenp/deploy/CrimePortal.ear/
> 10:32:01,401 INFO  [STDOUT] javax.management.InstanceNotFoundException: jboss.management.local:J2EEApplication=CrimePortal.ear,J2EEServer=Local,j2eeType=EJBModule,name=CrimePortalBeans.jar is not registered.
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
> 10:32:01,406 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.getMBeanInfo(MBeanServerImpl.java:651)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDeployedObjects(JSR77Lister.java:167)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServer(JSR77Lister.java:194)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createServers(JSR77Lister.java:218)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomain(JSR77Lister.java:233)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.createDomains(JSR77Lister.java:256)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.JSR77Lister.getTreeForResource(JSR77Lister.java:282)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.plugins.helpers.AbstractPluginWrapper.getSubTreeForResource(AbstractPluginWrapper.java:201)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreesForResource(PluginManager.java:392)
> 10:32:01,410 INFO  [STDOUT]     at org.jboss.console.manager.PluginManager.getTreeForProfile(PluginManager.java:192)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 10:32:01,410 INFO  [STDOUT]     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 10:32:01,411 INFO  [STDOUT]     at java.lang.reflect.Method.invoke(Method.java:324)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.processRequest(InvokerServlet.java:90)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.console.remote.InvokerServlet.doPost(InvokerServlet.java:133)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 10:32:01,411 INFO  [STDOUT]     at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 10:32:01,411 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,411 INFO  [STDOUT]     at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> 10:32:01,412 INFO  [STDOUT]     at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 10:32:01,412 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 10:32:01,430 INFO  [STDOUT]     at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 10:32:01,430 INFO  [STDOUT]     at java.lang.Thread.run(Thread.java:534)
> 1

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3188) Reduce the
 dependencies specified
 by web-console so it can be installed in more profiles.
Message-ID: <1978046.1158577021368.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3188?page=all ]

Dimitris Andreadis updated JBAS-3188:
-------------------------------------

    Component/s: Web Console
                     (was: Installer)

> Reduce the dependencies specified by web-console so it can be installed in more profiles.
> -----------------------------------------------------------------------------------------
>
>                 Key: JBAS-3188
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3188
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console has been implemented to it is not strictly dependent on the components it makes available through it's interface, if any component it makes available through the interface is not installed then initialisation will fail just for that component and it will not be added to the tree.  The remaining components will still be added to the tree and the web-console will continue to work correctly.
> The installer should be updated so the web-console is dependent on less components so it can be installed in more profiles.
> This will also get rid of another problem where the web console is dependent on specifc versions of components e.g. At the moment it is dependent on the JDK 1.4 version of AOP so can not be installed in any profile that uses the JDK 5.0 version of AOP.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2008) web console
 statistics view does not show properly in Firefox
Message-ID: <20554802.1158577021559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2008?page=all ]

Dimitris Andreadis updated JBAS-2008:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse

> web console statistics view does not show properly in Firefox
> -------------------------------------------------------------
>
>                 Key: JBAS-2008
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2008
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Firefox
>            Reporter: Kevin Barfield
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>
> The statistics view in the web console has a box though it when viewed through the Firefox browser.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <617409.1158577021735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3402) Web Console and
	Firefox
In-Reply-To: <5847131.1153247531914.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5794340.1158577141594.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3402?page=all ]

Dimitris Andreadis updated JBAS-3402:
-------------------------------------

    Component/s: Web Console
                     (was: Management services)
       Assignee: Darran Lofthouse  (was: Dimitris Andreadis)

> Web Console and Firefox
> -----------------------
>
>                 Key: JBAS-3402
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3402
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: MS W2000 SP4
>            Reporter: Vladimir Gendler
>         Assigned To: Darran Lofthouse
>         Attachments: Snapshots.zip
>
>
> Web Console output in Mozilla Firefox (and Seamonkey)
> is messed up. Compare the attached archive with
> snapshots from Mozilla Firefox and MSIE.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2008) web console
 statistics view does not show properly in Firefox
Message-ID: <24160531.1158577141757.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2008?page=all ]

Dimitris Andreadis updated JBAS-2008:
-------------------------------------

    Comment: was deleted

> web console statistics view does not show properly in Firefox
> -------------------------------------------------------------
>
>                 Key: JBAS-2008
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2008
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Firefox
>            Reporter: Kevin Barfield
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>
> The statistics view in the web console has a box though it when viewed through the Firefox browser.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 06:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 06:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1901) web-console shows
 dead archives after redeploy
Message-ID: <8931821.1158577141913.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1901?page=all ]

Dimitris Andreadis updated JBAS-1901:
-------------------------------------

    Comment: was deleted

> web-console shows dead archives after redeploy
> ----------------------------------------------
>
>                 Key: JBAS-1901
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1901
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Bill Burke
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> if you redeploy an ear multiple times you will see it show up multiple times
> under the web-console/j2ee applications tree in the applet.  If you try to browse one of those dead archives, it will blow up the j2ee applications tree structure

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:07:01 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 18 Sep 2006 07:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBRULES-499) Rule not
 rendering activation group correctly
In-Reply-To: <18329106.1158574737302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14239661.1158577621346.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-499?page=all ]

Michael Neale resolved JBRULES-499.
-----------------------------------

    Fix Version/s: 3.0.5
                   3.1-m1
       Resolution: Done

> Rule not rendering activation group correctly
> ---------------------------------------------
>
>                 Key: JBRULES-499
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-499
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>    Affects Versions: 3.0.4
>            Reporter: Michael Neale
>         Assigned To: Michael Neale
>             Fix For: 3.0.5, 3.1-m1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:13:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2131) Better support for
 BMT SFSB "mistakes"
Message-ID: <18651459.1158577981428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2131?page=all ]

Dimitris Andreadis updated JBAS-2131:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Weston Price

Weston, do you want to have a go with this, for the next release?

> Better support for BMT SFSB "mistakes"
> --------------------------------------
>
>                 Key: JBAS-2131
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2131
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions:  JBossAS-4.0.3RC2
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Further to JBAS-2128 we should also implement some sort of listener on the transaction timeout.
> Given the stupid BMT SFSB semantics (this part of the spec is one my favourite anti-patterns :-)
> where a client can hog server resources.
> sfsb.doBegin();
> doLongRunningProcess();
> sfsb.doCommit();
> And even crash during the doLongRunningProcess().
> We should allow the server to reclaim the resources from a transaction timeout more quickly.
> Another option would be to allow a configuration that does a rollback() at transaction timeout.
> But this would require some serious testing to make sure all JBoss code is checking transaction status correctly.
> It would also confuse any non-j2ee compliant framework that registers transaction synchronizations
> and then assumes their "thread local" is still valid from the timeout thread or they aren't threadsafe. 
> No names mentioned to protect the guilty :-)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:15:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2037) Bug in the JBoss
	HTML adaptor.
Message-ID: <31884569.1158578101361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2037?page=all ]

Dimitris Andreadis reassigned JBAS-2037:
----------------------------------------

    Assignee: Amit Bhayani

Amit, more jmx-console stuff, if you want to have a look.

> Bug in the JBoss HTML adaptor.
> ------------------------------
>
>                 Key: JBAS-2037
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2037
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMX
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.0 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-3.2.5 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1RC1, JBossAS-4.0.1 SP1,  JBossAS-4.0.3RC1
>            Reporter: jean deruelle
>         Assigned To: Amit Bhayani
>             Fix For: JBossAS-4.0.6.CR1
>
>
> "The set of characters in a value is also limited. If
> special characters may occur, it is recommended that the
> value be quoted, using ObjectName.quote. If the value for a
> given key is sometimes quoted, then it should always be
> quoted. By default, if a value is a string (rather than a
> number, say), then it should be quoted unless you are sure
> that it will never contain special characters." quoted from
> java management best practices (see
> http://java.sun.com/products/JavaManagement/best-practices.html#mozTocId654884
> in section ObjectNameSyntax)
> When a JMX value is quoted, it causes problems to invoke methods through thr Jboss jmx web console :
> So my feeling is that the problem comes from the jboss jmx
> console jsp pages.
> The thing is that the quotes in the jmx object name are not
> encoded to the html format in the jsp pages and so the first
> opening quote is interpreted as the final quote of the html
> field.
> Here is a quick fix for Jboss-3.2.6 :
> Add the following lines to
> %JBOSS_HOME%\server\all\deploy\jmx-console.war\inspectMBean.jsp
> after line 141
> <%objectNameString=objectNameString.replaceAll("\"","&quot;");
> //objectNameString=URLEncoder.encode(objectNameString);%>
> It was a quick fix to fit my needs but the
> line should really be the one commented but in that case the
> HtmlAdaptorServlet from Jboss cannot handle it correctly
> because it doesn't do a URLDecoder.decode of the
> objectNameString stored in the request parameter called "name".
> But I might be wrong here in saying that it comes from
> jboss, maybe I missed something along the way. 
> Can someone confirm this bug or help me out there ?
> Thx
> Best regards
> Jean

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:17:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1984)
 HttpNamingContextFactory unable to reconnect
Message-ID: <26278841.1158578221801.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1984?page=all ]

Dimitris Andreadis updated JBAS-1984:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Tom  Elrod

Maybe Tom, can take a look at this case, for the next release.

> HttpNamingContextFactory unable to reconnect
> --------------------------------------------
>
>                 Key: JBAS-1984
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1984
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming, Remoting
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: XP
>            Reporter: Bernd Eckenfels
>         Assigned To: Tom  Elrod
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Unlike the normal JNP/RMI Connection the HttpNamingContextFactory created Context does not recover from a application server shutdown. If I repeat lookups, the exception after the application server is available again looks like this:
> ex: javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: http://127.0.0.1:8080/invoker/JNDIFactory [Root exception is javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1363)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:575)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:568)
> 	at net.eckenfels.JNDITest.main(JNDITest.java:72)
> Caused by: javax.naming.CommunicationException: Failed to connect to server http:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:250)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1348)
> 	... 3 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server http:1099 [Root exception is java.net.UnknownHostException: http: http]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:224)
> 	... 4 more
> Caused by: java.net.UnknownHostException: http: http
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1128)
> 	at java.net.InetAddress.getAllByName0(InetAddress.java:1098)
> 	at java.net.InetAddress.getAllByName(InetAddress.java:1061)
> 	at java.net.InetAddress.getByName(InetAddress.java:958)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:61)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:220)
> 	... 4 more
> Note the Unknown Host Exception, which looks pretty much like a destroyed or miss-parsed URL. Since the connection work with the same InitialContext instance before, the setup is correct:
> 		p.put("java.naming.factory.initial", "org.jboss.naming.HttpNamingContextFactory");
> 		p.put("java.naming.provider.url", "http://127.0.0.1:8080/invoker/JNDIFactory");
> 		p.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
> 		p.put("jnp.disableDiscovery", "true");
>                Context rootCtx = (Context)new InitialContext(p);
> 		while(true)
> 		{
> 			try
> 			{
> 			// rootCtx = new InitialContext(p);
> 			Context jmxCtx = (Context)rootCtx.lookup("/jmx/rmi");
> 			l = jmxCtx.list("");
> 			while(l.hasMore())
> 			{
> 				System.out.println(" - " + l.next());
> 			}
> 			} catch (Throwable t) {
> 				System.out.println("ex: " + t); t.printStackTrace(System.out);
> 			}
> 			try{Thread.sleep(10000);}catch(Throwable t) { }
> 		}
> This sample code works if i uncomment the re-creation of the InitialContext, however this is neighter needed by the JNP/RMI Version nor does the exception look like sane handling.
> The client is using jbossall-client.jar and jdk 1.5_04. Jboss 3.2.7 is running (unmodified default profile) on 1.5, too. Problem exists with 3.2.6, too.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:21:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1728)
 Statement.getConnection not working for remote client
Message-ID: <11023182.1158578461884.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1728?page=all ]

Dimitris Andreadis updated JBAS-1728:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)
         Assignee: Weston Price

> Statement.getConnection not working for remote client
> -----------------------------------------------------
>
>                 Key: JBAS-1728
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1728
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> the org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService is not handling Statement.getConnection. It returns the real thing instead of a proxy --> Serialization exception!!.
> This is related to JBAS-1678.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:21:02 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1728)
 Statement.getConnection not working for remote client
Message-ID: <9652902.1158578462104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1728?page=all ]

Dimitris Andreadis updated JBAS-1728:
-------------------------------------

    Component/s: JCA service
                     (was: Remoting)

> Statement.getConnection not working for remote client
> -----------------------------------------------------
>
>                 Key: JBAS-1728
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1728
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> the org.jboss.resource.adapter.jdbc.remote.WrapperDataSourceService is not handling Statement.getConnection. It returns the real thing instead of a proxy --> Serialization exception!!.
> This is related to JBAS-1678.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:33:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-2398) Check for
 unparameterized interface configuration
Message-ID: <13843010.1158579181244.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2398?page=all ]

Dimitris Andreadis resolved JBAS-2398.
--------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

>From my tests (detailed in the forum post), using -b correctly binds the various ports. Only the jgroups stack may present a different behavior but the clustering team seems satisfied, or else somebody else can take it from here.

> Check for unparameterized interface configuration
> -------------------------------------------------
>
>                 Key: JBAS-2398
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2398
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.3 Final
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Make sure all interface configuration distributed with JBossAS uses the
> ${jboss.bind.address:0.0.0.0} pattern to pickup the standard system property.
> But be careful that 0.0.0.0 does not end up as a connection address for a client.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:35:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2193) abstract schema name
 with word limit in name
Message-ID: <31607242.1158579301372.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ]

Dimitris Andreadis updated JBAS-2193:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> abstract schema name with word limit in name
> --------------------------------------------
>
>                 Key: JBAS-2193
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2193
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions:  JBossAS-4.0.3RC1
>         Environment: OS: Windows XP and FreeBsd
> Database: PostgreSQL 7.4
>            Reporter: Yura Kravchuk
>         Assigned To: Alexey Loubyansky
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly.
> Herewith exception:
> 17:02:28,671 INFO  [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ
> ory; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.
> Was expecting:
>     "FROM" ...
>     ; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:43:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3272) update JBossRemoting
 to version 2.0.0
Message-ID: <5729459.1158579781301.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3272?page=all ]

Dimitris Andreadis updated JBAS-3272:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

We won't upgrade remoting for jboss 4.0.5.GA, since jbossws-1.0.4 (that work with remoting 2) will be release in Oct.

> update JBossRemoting to version 2.0.0
> -------------------------------------
>
>                 Key: JBAS-3272
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3272
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Need to update JBossAS to include jboss-remoting.jar for version 2.0.0.GA of JBossRemoting.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:45:01 2006
From: jira-events at jboss.com (Michael Neale (JIRA))
Date: Mon, 18 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-500) Special connective
 "or" constraint
Message-ID: <11735537.1158579901241.JavaMail.jira@cloud.prod.atl2.jboss.com>

Special connective "or" constraint
----------------------------------

                 Key: JBRULES-500
                 URL: http://jira.jboss.com/jira/browse/JBRULES-500
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Reteoo, Rule Assemply/SPI
            Reporter: Michael Neale
         Assigned To: Mark Proctor


Would be nice to have some construct like

Person(address == null or age < 30)

which would kind of short circuit (ideally). Could be done as a special thing with alpha nodes, or another type of join node, or something else. 

This is a common problem to have for users.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1182) Thread creation
 during deactivate_object
Message-ID: <21614621.1158580141378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1182?page=all ]

Dimitris Andreadis updated JBAS-1182:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

I still don't see any progress in the jacorb bugzilla

> Thread creation during deactivate_object
> ----------------------------------------
>
>                 Key: JBAS-1182
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1182
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>            Reporter: SourceForge User
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: kevinconner .
> This is a duplicate of bug 527 in the JacORB database.
>  It is being submitted here so that a patch may be
> applied to the JBoss patched version of JacORB.
> http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=527
> The deactiviation of an object causes Thread creation
> in AOM.remove.  Would it
> be possible to use a thread pool instead of creating
> new threads?
> A possible solution could be to have the
> RequestController provide a
> notification mechanism (instead of a thread waiting on
> object completion) and
> have the notification request work from the thread pool.
> The attached patch uses a threadpool to prevent the
> thread creation but I don't
> believe it is the best solution.
> Index: AOM.java
> ===================================================================
> RCS file:
> /cvsroot/jacorb/JacORB/src/org/jacorb/poa/AOM.java,v
> retrieving revision 1.29
> diff -u -r1.29 AOM.java
> --- AOM.java	6 May 2004 12:40:00 -0000	1.29
> +++ AOM.java	21 Oct 2004 14:38:11 -0000
> @@ -27,6 +27,9 @@
>  import org.jacorb.poa.util.ByteArrayKey;
>  import org.jacorb.poa.util.POAUtil;
>  import org.jacorb.poa.util.StringPair;
> +import org.jacorb.util.threadpool.Consumer;
> +import org.jacorb.util.threadpool.ConsumerFactory;
> +import org.jacorb.util.threadpool.ThreadPool;
>  
>  import
> org.omg.PortableServer.POAPackage.ObjectAlreadyActive;
>  import org.omg.PortableServer.POAPackage.ObjectNotActive;
> @@ -69,6 +72,23 @@
>      /** a lock to protect two consecutive operations
> on the list, used
>          in remove() */
>      private Object              deactivationListLock =
> new Object();
> +    
> +    private Consumer deactivationConsumer = new
> Consumer() {
> +        public void doWork(final Object job) {
> +            try {
> +                ((Runnable)job).run() ;
> +            } catch (final Throwable th) {
> +                logger.info("Unhandled exception
> during deactivation", th);
> +            }
> +        } 
> +    } ;
> +    private ConsumerFactory
> deactivationConsumerFactory = new ConsumerFactory() {
> +        public Consumer create() {
> +            return deactivationConsumer ;
> +        }
> +    } ;
> +    
> +    private ThreadPool deactivationPool = new
> ThreadPool(deactivationConsumerFactory) ;
>  
>      private AOM()
>      {
> @@ -348,8 +368,7 @@
>          final POA poa_ = poa;
>          final boolean cleanupInProgress_ =
> cleanupInProgress;
>  
> -        Thread thread = new Thread("AOM_RemovalThread")
> -        {
> +        final Runnable job = new Runnable() {
>              public void run()
>              {
>                  _remove(
> @@ -361,8 +380,8 @@
>                         );
>              }
>          };
> -
> -        thread.start();
> +        
> +        deactivationPool.putJob(job) ;
>      }

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1180) bi-pass JacORB
 interceptors for purely local invocations
Message-ID: <27637992.1158580141622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1180?page=all ]

Dimitris Andreadis updated JBAS-1180:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

I still don't see any progress in the jacorb bugzilla

> bi-pass JacORB interceptors for purely local invocations
> --------------------------------------------------------
>
>                 Key: JBAS-1180
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1180
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-3.2.6 Final
>            Reporter: SourceForge User
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: marklittle .
> I registered the following issue 
> (http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?
> id=526) with JacORB bugzilla a couple of weeks ago, but 
> no response so far. I think it's sufficiently important to 
> register here too in case you are able to do something 
> for JBoss.
> In the current implementation of JacORB (2.2), if I 
> register an interceptor with the ORB, then 
> it appears that all invocations to all objects go through 
> that interceptor, 
> even if they are co-located with the invoker. I 
> understand that rational given 
> the PI specification and the original intention behind 
> that work: to make 
> local invocations and remote invocations similar.
> However, most ORBs provide a way of doing a local, no-
> interceptor 
> optimization. The JDK 1.4 ORB is one example (though 
> that takes the other 
> extreme and won't invoke interceptors on any local 
> object).
> Orbix 2000, for example, supports multiple ORBs and 
> POAs within the same VM, 
> and interceptors are registered on a per-ORB basis, not 
> a per VM basis as 
> appears to be the case with JacORB. You can also turn 
> on local optimizations 
> for the individual ORBs.
> The reason for asking for this optimization is 
> performance. With a very simple 
> test, where the interceptor does nothing, we see a 66% 
> degredation in 
> performance for local calls. For example, with no 
> interceptors we can get > 3000 invocations, whereas 
> with a "null" interceptor this is around 1000.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:51:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2057) Need an EJB3 mbean
	JSR-77 mapping
Message-ID: <4848692.1158580261406.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2057?page=all ]

Dimitris Andreadis updated JBAS-2057:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Need an EJB3 mbean JSR-77 mapping
> ---------------------------------
>
>                 Key: JBAS-2057
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2057
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Management services, EJB3
>            Reporter: Scott M Stark
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Deployment of an ejb3 component should result in an jsr-77 ejb mbean for integration into the management tools. I don't know if an ejb3 deployment can just be treated as an ejb2.1 deployment by the LocalJBossServerDomain and this will just work.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 07:57:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 07:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-1941) JBoss-4.0.1Sp1
 startup slow (server hangs in SQLUtil.tableExists() method)
Message-ID: <9308878.1158580621354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1941?page=all ]

Dimitris Andreadis resolved JBAS-1941.
--------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Cannot Reproduce Bug

I've closing this, if it cannot be reproduced by Alexey.

> JBoss-4.0.1Sp1 startup slow (server hangs in SQLUtil.tableExists() method)
> --------------------------------------------------------------------------
>
>                 Key: JBAS-1941
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1941
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.1 SP1
>         Environment: Effect takes place on the Solaris (SunOS Release 5.8) as well as the Windows (XP) Platform. The System uses a DB2 Database (UDB Runtime Client V8.1 connects via DB2Connect to DB2 Server V7.0 running on OS390)
> I observed the same Effect on other JBoss releases (JBoss-3.2.5, JBoss-4.0.2)
>            Reporter: helly15
>         Assigned To: Alexey Loubyansky
>         Attachments: JBoss4_Startup 2005-06-21 17-59-35.profile
>
>
> I am moving from JBoss-3.2.1 to JBoss-4.0.1Sp1. The problem  I am facing is that it takes JBoss-4.0.1 over 10 minutes  to start,  while JBoss-3.2.1 started up in under 3 minutes. 
> I did a profiling of the startup process using the Eclipse Profiler.  The profiling revealed that the server spends nearly 10 seconds in the method SQLUtil.tableExists()  every time the method is called during the startup process. This method is called once for every table that exists in the application (32 tables). This leads to the lengthy startup time.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:29:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 08:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3625) Update EJB3 for
	jboss-4.0.5.GA
In-Reply-To: <13328214.1157537614191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1488013.1158582541246.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3625?page=all ]

Dimitris Andreadis closed JBAS-3625.
------------------------------------

    Resolution: Done

> Update EJB3 for jboss-4.0.5.GA
> ------------------------------
>
>                 Key: JBAS-3625
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3625
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> Merge EJB3 changes to Branch_4_0, take care of any library dependency issues (e.g. new remoting version required?)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:33:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Mon, 18 Sep 2006 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-702) Quartz Timer
 Service in E-EJB3 hangs process, exception on shutdown
In-Reply-To: <1150389.1158281915419.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32865892.1158582781249.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-702?page=comments#action_12343472 ] 
            
Carlo de Wolf commented on EJBTHREE-702:
----------------------------------------

     [java] java.lang.NullPointerException
     [java]     at javax.naming.InitialContext.getURLScheme(InitialContext.java:228)
     [java]     at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:277)
     [java]     at javax.naming.InitialContext.lookup(InitialContext.java:351)
     [java]     at org.quartz.utils.JNDIConnectionProvider.init(JNDIConnectionProvider.java:127)
     [java]     at org.quartz.utils.JNDIConnectionProvider.<init>(JNDIConnectionProvider.java:86)
     [java]     at org.jboss.ejb3.timerservice.quartz.QuartzTimerServiceFactory.setDataSource(QuartzTimerServiceFactory.java:220)


> Quartz Timer Service in E-EJB3 hangs process, exception on shutdown
> -------------------------------------------------------------------
>
>                 Key: EJBTHREE-702
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-702
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> to test this out:
> build embedded.dist
> go run one of the tutorials.  You will see that the applicatoin will never exit.  I'm guessing this is becuase a Quartz thread is a non-daemon thread and holding up the exit of the process.  Also there is a NullPointerException on shutdown.  I have disabled the Quartz Timer Service in embedded-jboss-beans.xml for now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:57:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Mon, 18 Sep 2006 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-285) overridden method
 super calls do not get intercepted with generated advisors
In-Reply-To: <19742940.1158252037003.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <258960.1158584221265.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-285?page=all ]

Kabir Khan updated JBAOP-285:
-----------------------------

    Summary: overridden method super calls do not get intercepted with generated advisors  (was: overloaded method super calls do not get intercepted with generated advisors)

> overridden method super calls do not get intercepted with generated advisors
> ----------------------------------------------------------------------------
>
>                 Key: JBAOP-285
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-285
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> class Base{
>    void superCall(){}
> }
> class Sub extends Base{
>    void superCall(){super.superCall();}
> }
> <bind pointcut="execution(* $instanceof{Base}->superCall())">
>    <interceptor class="X"/>
> </bind>
> Sub sub = new Sub();
> sub.superCall();
> We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. 
> I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 08:57:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Mon, 18 Sep 2006 08:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-285) overridden method
 super calls do not get intercepted with generated advisors
In-Reply-To: <19742940.1158252037003.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22086361.1158584221393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-285?page=all ]

Kabir Khan closed JBAOP-285.
----------------------------

    Resolution: Done

> overridden method super calls do not get intercepted with generated advisors
> ----------------------------------------------------------------------------
>
>                 Key: JBAOP-285
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-285
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha
>
>
> class Base{
>    void superCall(){}
> }
> class Sub extends Base{
>    void superCall(){super.superCall();}
> }
> <bind pointcut="execution(* $instanceof{Base}->superCall())">
>    <interceptor class="X"/>
> </bind>
> Sub sub = new Sub();
> sub.superCall();
> We only get intercepted when calling sub.superCall(), the call to base.superCall() does not get intercepted. 
> I added a failing test to org.jboss.test.aop.extender.ExtenderTestCase

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:40:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3665) Update JBoss
	Serialization
Message-ID: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JBoss Serialization
--------------------------

                 Key: JBAS-3665
                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
            Priority: Critical
             Fix For: JBossAS-4.0.5.GA


There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:40:01 2006
From: jira-events at jboss.com (Mladen Turk (JIRA))
Date: Mon, 18 Sep 2006 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17259519.1158586801349.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343476 ] 
            
Mladen Turk commented on JBAS-3495:
-----------------------------------

Actually we have the service wrapper that allows to run any .bat script as a service.
It even works on WIN32, WIN64/AMD64 and WIN64/IA64 natively.

The code is part of JBossWeb build and is part of JBossWeb binary distribution (.zip)
New code is at:
http://anonsvn.jboss.org/repos/jbossnative/trunk/utils/windows/native/service/jbosssvc/


> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:40:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 09:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
In-Reply-To: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16857595.1158586801515.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-89?page=all ]

Clebert Suconic updated JBSER-89:
---------------------------------

    Fix Version/s: 1.0.3 GA

> StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSER-89
>                 URL: http://jira.jboss.com/jira/browse/JBSER-89
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.1 GA, 1.0.2 GA
>            Reporter: Manik Surtani
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA
>
>
> See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:42:56 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 09:42:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-86) The distribution jar
 manifest contains obsolete version information
In-Reply-To: <7606513.1155111192460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22763529.1158586976078.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-86?page=all ]

Clebert Suconic updated JBSER-86:
---------------------------------

    Fix Version/s: 1.0.3 GA

> The distribution jar manifest contains obsolete version information
> -------------------------------------------------------------------
>
>                 Key: JBSER-86
>                 URL: http://jira.jboss.com/jira/browse/JBSER-86
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.2 GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.3 GA
>
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: JBoss Inc.
> version: 1.0.0.RC1
> Main-Class: org.jboss.serial.Version

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:47:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 18 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2193) abstract schema name
 with word limit in name
Message-ID: <5979431.1158587221437.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2193?page=all ]

Alexey Loubyansky closed JBAS-2193.
-----------------------------------

    Fix Version/s:     (was: JBossAS-4.0.6.CR1)
       Resolution: Out of Date

This one was probably fixed as a side effect of some other issue. It's working against the current Branch_4_0.
15:42:00,685 INFO  [FacadeSessionBean] RUN>
15:42:00,685 DEBUG [A#ejbSelectSelect] DYNAMIC-QL: select count(limit_a.id) from limita limit_a
15:42:00,685 DEBUG [A#ejbSelectSelect] Executing SQL: SELECT count( t0_limit_a.id) FROM A t0_limit_a
15:42:00,685 INFO  [STDOUT] [1]

> abstract schema name with word limit in name
> --------------------------------------------
>
>                 Key: JBAS-2193
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2193
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions:  JBossAS-4.0.3RC1
>         Environment: OS: Windows XP and FreeBsd
> Database: PostgreSQL 7.4
>            Reporter: Yura Kravchuk
>         Assigned To: Alexey Loubyansky
>            Priority: Minor
>
> We have few CMP entity beans with abstract schema name with word "limit", e.g. limitation_categories, limitation_durations, etc. We using dynamiq QL. It seems that query parser confused by word "limit" in schema name and thinks that it's clause LIMIT which placed before FROM clause. I changed schema name to lim_categories for entity bean and all works perfectly.
> Herewith exception:
> 17:02:28,671 INFO  [STDOUT] javax.ejb.EJBException: SELECT COUNT($limit_category.id) FROM limit_category AS $limit_categ
> ory; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.
> Was expecting:
>     "FROM" ...
>     ; CausedByException is:
>         Can't count entities by expression and parameters; CausedByException is:
>         Error compiling ejbql: org.jboss.ejb.plugins.cmp.ejbql.ParseException: Encountered "<EOF>" at line 1, column 71.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:53:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-58) Add back EPR
	functionality
Message-ID: <30410377.1158587581719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-58?page=all ]

Mark Little closed JBESB-58.
----------------------------

    Resolution: Done

> Add back EPR functionality
> --------------------------
>
>                 Key: JBESB-58
>                 URL: http://jira.jboss.com/jira/browse/JBESB-58
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> Prior to Rosetta, the Alpha 1 codebase has the EPR capabilities. Add this back.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:53:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31760280.1158587581871.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little updated JBESB-118:
------------------------------

    Fix Version/s: 4.0
                       (was: 4.1)

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.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

        


From jira-events at jboss.com  Mon Sep 18 09:53:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13828712.1158587582020.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little updated JBESB-118:
------------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.)]

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.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

        


From jira-events at jboss.com  Mon Sep 18 09:53:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-105) Use a true UID
	implementation
In-Reply-To: <25693193.1154528711566.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16145339.1158587582185.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-105?page=all ]

Mark Little updated JBESB-105:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Use a true UID implementation
> -----------------------------
>
>                 Key: JBESB-105
>                 URL: http://jira.jboss.com/jira/browse/JBESB-105
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.1
>
>
> The core code uses the notion of a UID, but seems to only use a long. If this needs to be unique, then we need to look at using a proper UID 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

        


From jira-events at jboss.com  Mon Sep 18 09:53:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:53:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-62) Change jar names
Message-ID: <31453459.1158587582337.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-62?page=all ]

Mark Little updated JBESB-62:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Change jar names
> ----------------
>
>                 Key: JBESB-62
>                 URL: http://jira.jboss.com/jira/browse/JBESB-62
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:57:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 18 Sep 2006 09:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-125) Installer
In-Reply-To: <9494883.1155053112755.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14888443.1158587821619.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-125?page=all ]

Mark Little updated JBESB-125:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Installer
> ---------
>
>                 Key: JBESB-125
>                 URL: http://jira.jboss.com/jira/browse/JBESB-125
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 09:57:02 2006
From: jira-events at jboss.com (Sverker Abrahamsson (JIRA))
Date: Mon, 18 Sep 2006 09:57:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25945443.1158587822225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Sverker Abrahamsson updated JBPORTAL-998:
-----------------------------------------

    Attachment: eclipse-2.6.patch

This patch is on the 2.6 tree, the previous patch file was on the 2.4 tree.

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse-2.6.patch, eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:05:01 2006
From: jira-events at jboss.com (James Callaghan (JIRA))
Date: Mon, 18 Sep 2006 10:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-587) GPD crashes if
 xmlbuddy plugin is installed
Message-ID: <2109524.1158588301988.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-587?page=comments#action_12343480 ] 
            
James Callaghan commented on JBPM-587:
--------------------------------------

I don't have XML buddy either and the GDP is unusable. It just crashes as soon as I open a process. I do however have JBoss IDE 1.5.0 so that seems to be something I have in common with Carmine.

> 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: Tom Baeyens
>
> 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

        


From jira-events at jboss.com  Mon Sep 18 10:19:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3665) Update JBoss
	Serialization
In-Reply-To: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6827029.1158589141412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3665?page=all ]

Clebert Suconic reassigned JBAS-3665:
-------------------------------------

    Assignee: Clebert Suconic

> Update JBoss Serialization
> --------------------------
>
>                 Key: JBAS-3665
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:31:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1082)
 jdbc.WrapperDataSource.getConnection is slow
Message-ID: <5003799.1158589861766.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1082?page=all ]

Clebert Suconic updated JBAS-1082:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> jdbc.WrapperDataSource.getConnection is slow
> --------------------------------------------
>
>                 Key: JBAS-1082
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1082
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-3.2.6 Final
>            Reporter: Elias Ross
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> SourceForge Submitter: genman .
> I've been profiling JMS code.  When a JMS message is
> added to the server, the persistence manager locates an
> appropriate DataSource.
> Out of the time spent in
> org.jboss.mq.Connection.sendToServer, about 28% of the
> time is getting the database connection through 
> jdbc.WrapperDataSource.getConnection to do its work. 
> This is after the pool has been initialized, etc.  (40%
> is actual persistence, though most of it is the message
> serialization.)
> I suspect a lot of the work is calculating a hashCode
> on the javax.security.auth.Subject.  SubjectCriKey and
> SubjectKey should have this value cached.  Ideally,
> when one is accessing the local DB, none of this auth
> stuff should have to take place.  Looking at the source
> for Subject.java, the hash code is not kept.
> BaseConnectionManager2.allocateConnection %CPU=27.949
> %Time=27.963 calls=411
> Allocations I've seen:
> JBossManagedConnectionPool$SubjectActions
> is created 3284 times (for 411 getConnection calls)
> java.util.Properties (1642 times)
> (Disclaimer:  This was done through JBoss profiler,
> which may or may not create real numbers.  It does
> look, though, that CX is pretty slow for some operations.)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:35:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 18 Sep 2006 10:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3150) Cipher attribute in
 the SSL Connector is ignored
Message-ID: <31453186.1158590101716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3150?page=all ]

Anil Saldhana reassigned JBAS-3150:
-----------------------------------

    Assignee: Anil Saldhana

> Cipher attribute in the SSL Connector is ignored
> ------------------------------------------------
>
>                 Key: JBAS-3150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Security
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> Please refer to the forum thread for more information.
> Please investigate this issue.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:35:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3142) Add UnifiedInvoker
 (JBSer and JavaSer) into Version MatrixTestSuite
Message-ID: <11259369.1158590101883.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3142?page=all ]

Clebert Suconic updated JBAS-3142:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Add UnifiedInvoker (JBSer and JavaSer) into Version MatrixTestSuite
> -------------------------------------------------------------------
>
>                 Key: JBAS-3142
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3142
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:37:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1939) MBean getAttribute()
 launch NotSerializableException when invoked from a remote client
Message-ID: <15983579.1158590221429.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1939?page=all ]

Clebert Suconic updated JBAS-1939:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> MBean getAttribute() launch NotSerializableException when invoked from a remote client
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-1939
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1939
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Management services
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: jmx, twiddle
>            Reporter: Fabiano C. de Oliveira
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> when executing twiddle to get attribute from some MBeans a NotSerializableException java.io.NotSerializableException is launched.
> To reproduce this just type:
> D:\jboss-4.0.2\bin>twiddle.bat get "jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/" logger 
> How can this can be fixed ? Ignoring the Non serializable attributes, returning null to Nonserializable attributes, become invisible all non-serializable attribute ?

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:39:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 10:39:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <10260853.1158590397597.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 10:41:56 2006
From: jira-events at jboss.com (James Callaghan (JIRA))
Date: Mon, 18 Sep 2006 10:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-587) GPD crashes if
 xmlbuddy plugin is installed
Message-ID: <17493905.1158590516876.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-587?page=comments#action_12343481 ] 
            
James Callaghan commented on JBPM-587:
--------------------------------------

I tried to disable the JBoss IDE features and plugins but the GDP still crashed when you opened it. I re-installed eclipse from scratch and added the jBPM plugins and features manually. After restarting Eclipse, jBPM worked fine. I suppose I'll just have to start and stop JBoss from a command prompt :(

> 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: Tom Baeyens
>
> 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

        


From jira-events at jboss.com  Mon Sep 18 11:14:56 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Mon, 18 Sep 2006 11:14:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-545) Transaction
 edge cases and memory leak
Message-ID: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>

Transaction edge cases and memory leak
--------------------------------------

                 Key: JBMESSAGING-545
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Tim Fox
             Fix For: 1.0.1.CR5


There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.

We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).

We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.

Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.

In this case the manager may retry the commit, but we will have no record of the branch.

Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:41:55 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 11:41:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3554) Upgrade JBoss AS
 to use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7769886.1158594115632.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3554?page=comments#action_12343482 ] 
            
Dimitris Andreadis commented on JBAS-3554:
------------------------------------------

Stan, 1.1.4 is released now, yes?

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:50:55 2006
From: jira-events at jboss.com (Adrian Pillinger (JIRA))
Date: Mon, 18 Sep 2006 11:50:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-708) Bundled
 jboss-ejb3-all.jar is invalid in embeddable container
Message-ID: <22313758.1158594655833.JavaMail.jira@cloud.prod.atl2.jboss.com>

Bundled jboss-ejb3-all.jar is invalid in embeddable container
-------------------------------------------------------------

                 Key: EJBTHREE-708
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-708
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC9 - FD
         Environment: Linux, Maven, Java 5.
            Reporter: Adrian Pillinger
            Priority: Blocker


The classes that were bundled together to form the jboss-ejb3-all.jar of the embeddable container are not compatible.

I am calling the following code...

{code}
        EJB3StandaloneBootstrap.boot(null);
        
        Collection<URL> deployDirs = getDeployDirURLs();
        Collection<URL> persistenceArchives = getPersistenceArchiveURLs();
        
        deployer = EJB3StandaloneBootstrap.createDeployer();

        .... get deploy dirs ..

        deployer.getDeployDirs().addAll(deployDirs);
        deployer.create();
        deployer.start();
{code}

When the code gets to deployer.create(); it fails with the following stack trace

{noformat}
java.lang.NoSuchMethodError: org/jboss/ejb3/Ejb3Deployment.<init>(Lorg/jboss/ejb3/DeploymentUnit;Lorg/jboss/ejb3/EAR;)V
	at org.jboss.ejb3.embedded.EJB3StandaloneDeployment.<init>(EJB3StandaloneDeployment.java:49)
	at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.create(EJB3StandaloneDeployer.java:438)
	at com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:84)
	at com.dolby.pics.test.TestSetupWrapper.setUp(TestSetupWrapper.java:32)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.extensions.TestSetup.run(TestSetup.java:27)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
	at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:615)
	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
{noformat}

The error as you can see is an incompatability between 
{noformat}
org.jboss.ejb3.embedded.EJB3StandaloneDeployment 
{noformat}
and 
{noformat}
org.jboss.ejb3.Ejb3Deployment
{noformat}

I'm guessing that these are from different jars and have been bundled into the same jar without a compile any tests to check that they are compatible.

My code worked absolutely fine with alpha 8 of the embeddable container.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:52:54 2006
From: jira-events at jboss.com (Adrian Pillinger (JIRA))
Date: Mon, 18 Sep 2006 11:52:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-708) Bundled
 jboss-ejb3-all.jar is invalid in embeddable container
In-Reply-To: <22313758.1158594655833.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2403725.1158594774254.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-708?page=all ]

Adrian Pillinger updated EJBTHREE-708:
--------------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD

> Bundled jboss-ejb3-all.jar is invalid in embeddable container
> -------------------------------------------------------------
>
>                 Key: EJBTHREE-708
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-708
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>         Environment: Linux, Maven, Java 5.
>            Reporter: Adrian Pillinger
>            Priority: Blocker
>             Fix For: EJB 3.0 RC10 - FD
>
>
> The classes that were bundled together to form the jboss-ejb3-all.jar of the embeddable container are not compatible.
> I am calling the following code...
> {code}
>         EJB3StandaloneBootstrap.boot(null);
>         
>         Collection<URL> deployDirs = getDeployDirURLs();
>         Collection<URL> persistenceArchives = getPersistenceArchiveURLs();
>         
>         deployer = EJB3StandaloneBootstrap.createDeployer();
>         .... get deploy dirs ..
>         deployer.getDeployDirs().addAll(deployDirs);
>         deployer.create();
>         deployer.start();
> {code}
> When the code gets to deployer.create(); it fails with the following stack trace
> {noformat}
> java.lang.NoSuchMethodError: org/jboss/ejb3/Ejb3Deployment.<init>(Lorg/jboss/ejb3/DeploymentUnit;Lorg/jboss/ejb3/EAR;)V
> 	at org.jboss.ejb3.embedded.EJB3StandaloneDeployment.<init>(EJB3StandaloneDeployment.java:49)
> 	at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.create(EJB3StandaloneDeployer.java:438)
> 	at com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:84)
> 	at com.dolby.pics.test.TestSetupWrapper.setUp(TestSetupWrapper.java:32)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:615)
> 	at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> 	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> 	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> 	at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:615)
> 	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> 	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> {noformat}
> The error as you can see is an incompatability between 
> {noformat}
> org.jboss.ejb3.embedded.EJB3StandaloneDeployment 
> {noformat}
> and 
> {noformat}
> org.jboss.ejb3.Ejb3Deployment
> {noformat}
> I'm guessing that these are from different jars and have been bundled into the same jar without a compile any tests to check that they are compatible.
> My code worked absolutely fine with alpha 8 of the embeddable container.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 11:54:54 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 11:54:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <28719848.1158594894950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.6.CR1)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 12:18:53 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Mon, 18 Sep 2006 12:18:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3554) Upgrade JBoss AS
 to use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15494245.1158596333118.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3554?page=comments#action_12343483 ] 
            
Stan Silvert commented on JBAS-3554:
------------------------------------

Almost.  From the dev list and the wiki, it looks like they are working out the logistics of getting the release on the downloads page and finalizing the release announcement.

http://wiki.apache.org/myfaces/CoreRelease114



> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 12:38:51 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 12:38:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3601) Switch copyright
 to RedHat Middleware LLC
In-Reply-To: <5022893.1157131903947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4339621.1158597531402.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3601?page=comments#action_12343484 ] 
            
Dimitris Andreadis commented on JBAS-3601:
------------------------------------------

Updated build/copyright.txt in all branches.

> Switch copyright to RedHat Middleware LLC
> -----------------------------------------
>
>                 Key: JBAS-3601
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3601
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Something like:
> /*
> * JBoss, Home of Professional Open Source
> * Copyright 2006, Red Hat Middleware LLC., and individual contributors as indicated 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 12:40:57 2006
From: jira-events at jboss.com (Britt Miner (JIRA))
Date: Mon, 18 Sep 2006 12:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-753) Leaving a Superstate
 does not record a NodeLog
Message-ID: <11880179.1158597657146.JavaMail.jira@cloud.prod.atl2.jboss.com>

Leaving a Superstate does not record a NodeLog
----------------------------------------------

                 Key: JBPM-753
                 URL: http://jira.jboss.com/jira/browse/JBPM-753
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Britt Miner
         Assigned To: Tom Baeyens


Leaving a Superstate should persist a NodeLog, but doesn'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

        


From jira-events at jboss.com  Mon Sep 18 12:42:52 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Mon, 18 Sep 2006 12:42:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28558780.1158597772797.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-132?page=comments#action_12343485 ] 
            
Daniel Brum commented on JBESB-132:
-----------------------------------

Can you please clarify this one?  What's the issue with the TB exactly?

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.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

        


From jira-events at jboss.com  Mon Sep 18 12:44:51 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Mon, 18 Sep 2006 12:44:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22664145.1158597891950.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-130?page=comments#action_12343486 ] 
            
Daniel Brum commented on JBESB-130:
-----------------------------------

Mark, can you verify this one?  there is a 'product' folder in the Beta1 tagged version under SVN.  There is a TRUNK folder also which I don't think should be there though.

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 13:06:55 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Mon, 18 Sep 2006 13:06:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
In-Reply-To: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15934674.1158599215239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3654?page=comments#action_12343487 ] 
            
Sakthi Samabsivam commented on JBAS-3654:
-----------------------------------------

Thanks for the quick response. As told, I am trying to create dependency between components under the EAR and not between two EARs. 
I am referring a similar case https://na1.salesforce.com/50030000001Rs96?srPos=2&srKp=500 wherein your reponse says 

"The components of an EAR do support dependency, so you can have an EJB or WAR in 
one EAR <depends> on another EJB or WAR from a different EAR." 

I am trying to follow the same in my example. This works fine till 4.0.1 SP1, but fails in 4.0.3SP1, 4.0.4 GA.

Please find the EARs attached.

> The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC1,  JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Dimitris Andreadis
>
> When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
> for example.  I have two ears example1. ear and example2.ear.
> I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
> So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml
>  <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
> This depends is working till jboss 4.0.1
> It fails in 4.0.3 SP1 , 4.0.4 GA
> 15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
> ment:war=crimeportal.war,id=-1360680885
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
> e: (javax.security.jacc.PolicyContextException: Operation not allowed)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
>         at org.jboss.web.WebModule.startModule(WebModule.java:68)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at org.jboss.system.ServiceController.start(ServiceController.java:446)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy21.start(Unknown Source)
>         at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy9.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
> tScanner.java:319)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
> canner.java:507)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
> doScan(AbstractDeploymentScanner.java:192)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
> bstractDeploymentScanner.java:265)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
>         at org.jboss.Main.boot(Main.java:187)
>         at org.jboss.Main$1.run(Main.java:438)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:201)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
> ossPolicyConfiguration.java:160)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
>         ... 94 more
> Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
> tion: linkConfiguration from state:inService
>         at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:196)
>         ... 96 more
> 15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
> ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
> 15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 13:09:01 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Mon, 18 Sep 2006 13:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3654) The deploy
 dependency fails between WAR of one EAR and EJB of the other EAR.
In-Reply-To: <28324769.1158177997409.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3398355.1158599341384.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3654?page=all ]

Sakthi Samabsivam updated JBAS-3654:
------------------------------------

    Attachment: AppA.ear
                AppB.ear

Thanks for the quick response. As told, I am trying to create dependency between components under the EAR and not between two EARs. 
I am referring a similar case https://na1.salesforce.com/50030000001Rs96?srPos=2&srKp=500 wherein your reponse says

 "The components of an EAR do support dependency, so you can have an EJB or WAR in 
one EAR <depends> on another EJB or WAR from a different EAR."

 I am trying to follow the same in my example. This works fine till 4.0.1 SP1, but fails in 4.0.3SP1, 4.0.4 GA.

Please find the EARs attached.

> The deploy dependency fails between WAR of one EAR and EJB of the other EAR.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3654
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3654
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC1,  JBossAS-4.0.3RC2, JBossAS-4.0.4RC1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Dimitris Andreadis
>         Attachments: AppA.ear, AppB.ear
>
>
> When I try to setup a deployment order between two EARS using depends tag in the Jboss-web.xml of one EAR's WAR with other EAR's EJB component, it fails.
> for example.  I have two ears example1. ear and example2.ear.
> I want my example1.ear's war file to be deployed after the example2.ear's EJB component is deployed..
> So I am wrting this depends tag entry in my example1.ear's  WAR compoent jboss-web.xml
>  <depends>jboss.j2ee:url='FiboApp.ear',service=EARDeployment</depends>
> This depends is working till jboss 4.0.1
> It fails in 4.0.3 SP1 , 4.0.4 GA
> 15:52:24,359 WARN  [ServiceController] Problem starting service jboss.web.deploy
> ment:war=crimeportal.war,id=-1360680885
> org.jboss.deployment.DeploymentException: Error during deploy; - nested throwabl
> e: (javax.security.jacc.PolicyContextException: Operation not allowed)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:366)
>         at org.jboss.web.WebModule.startModule(WebModule.java:68)
>         at org.jboss.web.WebModule.startService(WebModule.java:46)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at org.jboss.system.ServiceController.start(ServiceController.java:446)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy21.start(Unknown Source)
>         at org.jboss.deployment.EARDeployer.start(EARDeployer.java:297)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy9.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymen
> tScanner.java:319)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentS
> canner.java:507)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.
> doScan(AbstractDeploymentScanner.java:192)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(A
> bstractDeploymentScanner.java:265)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanS
> upport.java:274)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMB
> eanSupport.java:230)
>         at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl
> ler.java:943)
>         at $Proxy0.start(Unknown Source)
>         at org.jboss.system.ServiceController.start(ServiceController.java:428)
>         at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy4.start(Unknown Source)
>         at org.jboss.deployment.SARDeployer.start(SARDeployer.java:285)
>         at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:737)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
> er.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
> or.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
> BeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
> java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
>         at $Proxy5.deploy(Unknown Source)
>         at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:453)
>         at org.jboss.system.server.ServerImpl.start(ServerImpl.java:330)
>         at org.jboss.Main.boot(Main.java:187)
>         at org.jboss.Main$1.run(Main.java:438)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: javax.security.jacc.PolicyContextException: Operation not allowed
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:201)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.linkConfiguration(JB
> ossPolicyConfiguration.java:160)
>         at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:347)
>         ... 94 more
> Caused by: org.jboss.util.state.IllegalTransitionException: No transition for ac
> tion: linkConfiguration from state:inService
>         at org.jboss.util.state.StateMachine.nextState(StateMachine.java:111)
>         at org.jboss.security.jacc.JBossPolicyConfiguration.validateState(JBossP
> olicyConfiguration.java:196)
>         ... 96 more
> 15:52:24,359 INFO  [EARDeployer] Started J2EE application: file:/C:/jboss/traini
> ng/JBossForAdvancedJ2EE/labs/jboss-4.x/server/default/deploy/FiboApp.ear
> 15:52:24,359 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss.web.deployment:war=crimeportal.war,id=-1360680885
>   State: FAILED
>   Reason: org.jboss.deployment.DeploymentException: Error during deploy; - neste
> d throwable: (javax.security.jacc.PolicyContextException: Operation not allowed)
>   I Depend On:
>     jboss.j2ee:url='FiboApp.ear',service=EARDeployment

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 13:22:50 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 18 Sep 2006 13:22:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3150) Cipher attribute in
 the SSL Connector is ignored
Message-ID: <25971741.1158600170467.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3150?page=all ]

Anil Saldhana resolved JBAS-3150.
---------------------------------

    Resolution: Rejected

I reject this as a bug for the following reason.

When the user configures a comma-separated list of ciphers, then there are two criteria that are applied to figure out the final cipher suite:

Requested Cipher Suite and the default cipher suite (provided by the JDK SSLSocketFactory)
http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSocketFactory.html 

So basically, if the user configures:  ciphers = "TEST_DUMMY"
then the request cipher suite is "TEST_DUMMY" where as the default cipher suite can be:
-------------------------------------------------------------------------------------------------------------------------------
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[0]=SSL_RSA_WITH_RC4_128_MD5
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[1]=SSL_RSA_WITH_RC4_128_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[2]=TLS_RSA_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[3]=TLS_DHE_RSA_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[4]=TLS_DHE_DSS_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[5]=SSL_RSA_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[6]=SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,343 ERROR [STDERR] Supported Cipher:[7]=SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[8]=SSL_RSA_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[9]=SSL_DHE_RSA_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[10]=SSL_DHE_DSS_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[11]=SSL_RSA_EXPORT_WITH_RC4_40_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[12]=SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[13]=SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[14]=SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[15]=TLS_RSA_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[16]=TLS_DHE_RSA_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[17]=TLS_DHE_DSS_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[18]=SSL_RSA_WITH_NULL_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[19]=SSL_RSA_WITH_NULL_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[20]=SSL_DH_anon_WITH_RC4_128_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[21]=TLS_DH_anon_WITH_AES_128_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[22]=TLS_DH_anon_WITH_AES_256_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[23]=SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[24]=SSL_DH_anon_WITH_DES_CBC_SHA
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[25]=SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
2006-09-18 12:05:21,359 ERROR [STDERR] Supported Cipher:[26]=SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
================================================================================================

Since the request cipher does not exist in the default cipher, the default cipher list applies.

Now, if I configure ciphers = "TEST_DUMMY,SSL_RSA_WITH_3DES_EDE_CBC_SHA"
then the logic would enable such that the final cipher will be restricted to "SSL_RSA_WITH_3DES_EDE_CBC_SHA"

=============================================================
ERROR [STDERR] Cipher:[0]=SSL_RSA_WITH_3DES_EDE_CBC_SHA
=============================================================


===============================================
protected String[] getEnabledCiphers(String arg0, String[] arg1)
   { 
      String[] baseCiphers =  super.getEnabledCiphers(arg0, arg1);
      //Print them out
      int len = baseCiphers != null ? baseCiphers.length: 0;
      
      for(int i = 0; i < len; i++)
      {
         System.err.println("Cipher:["+i+"]=" + baseCiphers[i]);
      }
      return baseCiphers;
   }
================================================


So the behavior is consistent with what is expected.  If the cipher suite
provided does not contain any of the default ciphers supported by the JDK,
then the default ciphers apply.

So in theory, you should have atleast one cipher that is supported by the JDK in your
cipher restriction.




> Cipher attribute in the SSL Connector is ignored
> ------------------------------------------------
>
>                 Key: JBAS-3150
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3150
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Security
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-3.2.8.SP1
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> Please refer to the forum thread for more information.
> Please investigate this issue.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:33:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 14:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <363734.1158604381750.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=comments#action_12343493 ] 
            
Clebert Suconic commented on JBMESSAGING-432:
---------------------------------------------

Tim,

I'm just changing ClientConnectionFactoryDeleage to change that client. If you could please verify if this is correct.

I have executed testcases and this didn't change any behavior.

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:35:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 14:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
Message-ID: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>

Replace the dom4j dependency with a jarjar'ed equivalent
--------------------------------------------------------

                 Key: JBAS-3666
                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:37:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 18 Sep 2006 14:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12334505.1158604621195.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3666?page=comments#action_12343494 ] 
            
Dimitris Andreadis commented on JBAS-3666:
------------------------------------------

Scott put the jarjard dom4j jar into the repository here:
http://repository.jboss.com/dom4j/1.6.1.jarjar

It contains the dom4j-jarjar.jar (which uses an org.jboss.dom4j root package namespace), and the jarjar build script.

All that is left is to update all the bootstrap modules which use dom4j(jmx/j2se/system/system-jmx) to use the new namespace. The dom4j jars could be embedded into one of these module output jars as an implementation detail to reduce the number of bootstrap jars if desired.

> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:39:09 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 14:39:09 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <21331661.1158604749620.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Clebert Suconic closed JBMESSAGING-432.
---------------------------------------

    Resolution: Done

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 14:55:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Mon, 18 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-355) Constructor
 injection of component dependencies
Message-ID: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>

Constructor injection of component dependencies
-----------------------------------------------

                 Key: JBSEAM-355
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
             Project: JBoss Seam
          Issue Type: Feature Request
            Reporter: Christian Bauer
            Priority: Minor


Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 

Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.

Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:13:02 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 15:13:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <19487692.1158606782844.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Clebert Suconic reopened JBMESSAGING-432:
-----------------------------------------

             

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:25:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <27837962.1158607501383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=comments#action_12343502 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-432:
---------------------------------------------

Disconnecting the client will make TIME_WAIT state TCP/IP connections accumulate again, so this is not the right fix.
Minor issue anyway, pushed for later, when we'll have time for it.

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:27:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <29300118.1158607621349.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov updated JBMESSAGING-432:
----------------------------------------

    Fix Version/s: 1.2.1
                       (was: 1.0.1.CR5)

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.2.1
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:49:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
In-Reply-To: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10172500.1158608941953.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-540?page=all ]

Ovidiu Feodorov updated JBMESSAGING-540:
----------------------------------------

    Fix Version/s: 1.2.1
                       (was: 1.0.1.CR5)

> A testsuite testing client and server on different IPs
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-540
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.1
>
>
> The current testsuite tests both client and server on the same network. 
> We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:51:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 15:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-529) Install TCK5
 locally and fix all errors that prevent Messaging from passing
In-Reply-To: <1651862.1156376026636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26388680.1158609061395.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-529?page=all ]

Ovidiu Feodorov closed JBMESSAGING-529.
---------------------------------------

    Resolution: Done

Provided that the CTS is patched as promised (http://jira.jboss.org/jira/browse/JBCTS-336), all JMS tests pass 100%.

> Install TCK5 locally and fix all errors that prevent Messaging from passing
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-529
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-529
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 15:55:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 18 Sep 2006 15:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-9) Mavenize Security
	Build
Message-ID: <24504065.1158609301211.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mavenize Security Build
-----------------------

                 Key: SECURITY-9
                 URL: http://jira.jboss.com/jira/browse/SECURITY-9
             Project: JBoss Security
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JBossSX
    Affects Versions: 2.0
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0


Need to convert the security build into a maven based build.

Reference:
http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation
https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:17:55 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 18 Sep 2006 16:17:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-323) Set shunning to false
 in both FD and GMS
Message-ID: <15586805.1158610675069.JavaMail.jira@cloud.prod.atl2.jboss.com>

Set shunning to false in both FD and GMS
----------------------------------------

                 Key: JGRP-323
                 URL: http://jira.jboss.com/jira/browse/JGRP-323
             Project: JGroups
          Issue Type: Task
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Optional
             Fix For: 2.4


should be the default, even if no value is set

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:39:50 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 16:39:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-432) One
 connection per unique JMS server leak
Message-ID: <3092678.1158611990506.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=comments#action_12343507 ] 
            
Clebert Suconic commented on JBMESSAGING-432:
---------------------------------------------

Can we just mark won't fix?

A proper fix here would require changes on the API anyway.


> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.2.1
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:43:50 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Mon, 18 Sep 2006 16:43:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3345) Synch up with
 tomcat6 based jbossweb as the bundled web container
Message-ID: <21629670.1158612230497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3345?page=all ]

Remy Maucherat resolved JBAS-3345.
----------------------------------

    Resolution: Done

> Synch up with tomcat6 based jbossweb as the bundled web container
> -----------------------------------------------------------------
>
>                 Key: JBAS-3345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service
>            Reporter: Scott M Stark
>         Assigned To: Remy Maucherat
>            Priority: Blocker
>             Fix For: JBossAS-5.0.0.Beta
>
>
> We need a tomcat6 based version of jbosseb as the bundled web container for the jboss5 release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:45:51 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 16:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <16404443.1158612351436.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov updated JBMESSAGING-432:
----------------------------------------

    Fix Version/s: 1.0.1.CR5
                       (was: 1.2.1)

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:45:51 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 16:45:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-432) One connection
 per unique JMS server leak
Message-ID: <25618972.1158612351760.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-432?page=all ]

Ovidiu Feodorov closed JBMESSAGING-432.
---------------------------------------

    Resolution: Won't Fix

> One connection per unique JMS server leak
> -----------------------------------------
>
>                 Key: JBMESSAGING-432
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-432
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR2
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> Methods on connection factory are executed in ConnectionFactoryDelegate on their own client.
> This clien is not closed after use, otherwise we end up running out of resources since after closing the client the socket connections are discarded by remoting and end up in the TIME_WAIT state, so cam quickly fill up.
> This means that for the lifetime of the VM there will be one socket connection per unique jms server. So a small leak.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 16:51:51 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 16:51:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11060871.1158612711288.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry closed JBCACHE-769.
------------------------------------

    Resolution: Done

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 1.4.0.SP2, 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:05:53 2006
From: jira-events at jboss.com (Levi Purvis (JIRA))
Date: Mon, 18 Sep 2006 17:05:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-709)
 javaee_web_services_client_1_2.xsd is missing
Message-ID: <18921498.1158613553517.JavaMail.jira@cloud.prod.atl2.jboss.com>

javaee_web_services_client_1_2.xsd is missing
---------------------------------------------

                 Key: EJBTHREE-709
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-709
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC9 - FD, EJB 3.0 RC10 - FD
            Reporter: Levi Purvis
            Priority: Minor


When using an ejb-jar.xml file (referencing ejb-jar_3_0.xsd) with an EJB3 deployment in RC9, the following exception will be thrown.  A work-around is to download http://java.sun.com/xml/ns/javaee/javaee_web_services_client_1_2.xsd and manually add it as schema/javaee_web_services_client_1_2.xsd to server/default/lib/jboss.jar using the command-line jar tool.

2006-09-18 16:31:21,367 | DEBUG | main | EJB3Deployer | create, wps.jar
2006-09-18 16:31:21,429 | DEBUG | main | EJB3Deployer | Deploying: file:/C:/Software/Programs/jboss-4.0.4.GA/server/default/deploy/wps.jar/
2006-09-18 16:31:21,429 | DEBUG | main | ServiceController | Creating service jboss.j2ee:service=EJB3,module=wps.jar
2006-09-18 16:31:21,429 | DEBUG | main | Ejb3Module | Creating jboss.j2ee:service=EJB3,module=wps.jar
2006-09-18 16:31:21,445 | DEBUG | main | JaccHelper | Initialising JACC Context for deployment: wps.jar
2006-09-18 16:31:21,523 | DEBUG | main | EjbJarDDObjectFactory | found ejb-jar.xml file:/C:/Software/Programs/jboss-4.0.4.GA/server/default/deploy/wps.jar/META-INF/ejb-jar.xml
2006-09-18 16:31:21,695 | DEBUG | main | JBossEntityResolver | Cannot resolve [publicID=null,systemID=file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_web_services_client_1_2.xsd]
2006-09-18 16:31:21,710 | WARN | main | SaxJBossXBParser | schema_reference.4: Failed to read schema document 'javaee_web_services_client_1_2.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not <xsd:schema>. @ file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_5.xsd[78,69]
2006-09-18 16:31:21,726 | DEBUG | main | Ejb3Module | Initialization failed jboss.j2ee:service=EJB3,module=wps.jar
org.jboss.xb.binding.JBossXBException: Failed to parse source: src-resolve: Cannot resolve the name 'javaee:service-refGroup' to a(n) 'group' component. @ file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_5.xsd[798,49]
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:141)
	at org.jboss.xb.binding.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:190)
	at org.jboss.ejb3.metamodel.EjbJarDDObjectFactory.parse(EjbJarDDObjectFactory.java:87)
	at org.jboss.ejb3.Ejb3HandlerFactory$DDFactory.<init>(Ejb3HandlerFactory.java:44)
	at org.jboss.ejb3.Ejb3HandlerFactory.getInstance(Ejb3HandlerFactory.java:83)
	at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:349)
	at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:305)
	at org.jboss.ejb3.Ejb3Module.createService(Ejb3Module.java:77)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:260)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:243)
	at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.create(Unknown Source)
	at org.jboss.system.ServiceController.create(ServiceController.java:330)
	at org.jboss.system.ServiceController.create(ServiceController.java:273)
	at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy34.create(Unknown Source)
	at org.jboss.ejb3.EJB3Deployer.create(EJB3Deployer.java:429)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
	at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
	at org.jboss.ws.server.WebServiceDeployer.create(WebServiceDeployer.java:99)
	at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.create(SubDeployerInterceptorSupport.java:180)
	at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:91)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy35.create(Unknown Source)
	at org.jboss.deployment.MainDeployer.create(MainDeployer.java:953)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:807)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy6.deploy(Unknown Source)
	at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
	at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
	at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
	at $Proxy0.start(Unknown Source)
	at org.jboss.system.ServiceController.start(ServiceController.java:417)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy4.start(Unknown Source)
	at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
	at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1007)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:808)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
	at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:755)
	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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
	at $Proxy5.deploy(Unknown Source)
	at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
	at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
	at org.jboss.Main.boot(Main.java:200)
	at org.jboss.Main$1.run(Main.java:464)
	at java.lang.Thread.run(Thread.java:595)
Caused by: org.xml.sax.SAXException: src-resolve: Cannot resolve the name 'javaee:service-refGroup' to a(n) 'group' component. @ file:///C:/Software/Programs/jboss-4.0.4.GA/bin/javaee_5.xsd[798,49]
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser$MetaDataErrorHandler.error(SaxJBossXBParser.java:322)
	at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
	at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDGroupTraverser.traverseLocal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSeqChoice(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSequence(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDGroupTraverser.traverseGlobal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDGroupTraverser.traverseLocal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSeqChoice(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDAbstractParticleTraverser.traverseSequence(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.processComplexContent(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseComplexTypeDecl(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDComplexTypeTraverser.traverseGlobal(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.traverseSchemas(Unknown Source)
	at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.findSchemaGrammar(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement(Unknown Source)
	at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
	at org.apache.xerces.impl.XMLNSDocumentScannerImpl$NSContentDispatcher.scanRootElementHook(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
	at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
	at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
	at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.parse(SaxJBossXBParser.java:137)
	... 120 more


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:13:51 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:13:51 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29122372.1158614031589.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry reopened JBCACHE-769:
--------------------------------------

             
Reopening; forget to check BdbjeCacheLoader and JdbmCacheLoader.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:15:49 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Mon, 18 Sep 2006 17:15:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1050) WSRP consumer
 will throw an
 NPE if the markup response from the producer is an empty string.
Message-ID: <9582939.1158614149445.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP consumer will throw an NPE if the markup response from the producer is an empty string.
--------------------------------------------------------------------------------------------

                 Key: JBPORTAL-1050
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1050
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:23:50 2006
From: jira-events at jboss.com (john mendonca (JIRA))
Date: Mon, 18 Sep 2006 17:23:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <32393951.1158614630568.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

john mendonca updated JBAS-3641:
--------------------------------

    Attachment: jboss_init_hpux.sh

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh, jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:27:48 2006
From: jira-events at jboss.com (john mendonca (JIRA))
Date: Mon, 18 Sep 2006 17:27:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <9971196.1158614868821.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

john mendonca updated JBAS-3641:
--------------------------------


I've tested jboss_init_hpux.sh with 4.0.5.CR1 as requested.

I took the opportunity to make further changes to the script before testing:
- additional error checks (for userid, permissions, java or JAVA_HOME)
- always wait up for up to 30 seconds for JBoss to terminate gracefully

Cheers,
- John

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>         Attachments: jboss_init_hpux.sh, jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7819207.1158616069115.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25721216.1158616069279.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25320856.1158616069400.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:47:49 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:47:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30919774.1158616069530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry updated JBCACHE-769:
-------------------------------------

    Comment: was deleted

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:52 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30653799.1158616192785.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=comments#action_12343512 ] 
            
Clebert Suconic commented on JBMESSAGING-525:
---------------------------------------------

I have tested this basically by deploying a postgres datasource on a JBoss 4.0 and didn't find any issues.

The SQL look ok to me also, since I have a lot of experience with SQL.


So, the patch was applied.

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Beta1, 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:52 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 18 Sep 2006 17:49:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-769) JDBCCacheLoader
 should not directly serialize a map passed to put
In-Reply-To: <23111501.1158289541985.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20112256.1158616193004.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-769?page=all ]

Brian Stansberry closed JBCACHE-769.
------------------------------------

    Resolution: Done

JDBCCacheLoader, AsyncCacheLoader, and BdbjeCacheLoader were fixed in both HEAD and Branch_1_4_0.  In HEAD the new AbstractCacheLoader was fixed as well.  Other CacheLoader impls were already OK.

> JDBCCacheLoader should not directly serialize a map passed to put
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-769
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-769
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2.3, 1.3.0, 1.2.4, 1.4.0, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: 1.4.0.SP2, 2.0.0
>
>
> If a user calls TreeCache.put(Fqn, Map), the passed in Map gets passed to JDBCCacheLoader.put() which then directly serializes it to the database.  Then if a later put(fqn, key, value) comes in and the cache loader needs to deserialize the node data, the Map that was originally passed in gets deserialized and directly modified with the new key/value.
> Problem here is if the map originally passed in as an UnmodifiableMap, the update will fail.  Customer reported this happening.  FileCacheLoader didn't have the problem, as it makes a copy of the map before serializing.
> Solution is to do what FileCacheLoader does and make a defensive copy of the map before serializing.
> The other cache loaders should be checked as well.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2746623.1158616193159.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic closed JBMESSAGING-525.
---------------------------------------

    Resolution: Done

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28479696.1158616193329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic reopened JBMESSAGING-525:
-----------------------------------------

             

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Beta1, 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19324597.1158616193472.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic updated JBMESSAGING-525:
----------------------------------------

    Fix Version/s: 1.2.0.Beta1

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Beta1, 1.0.1.CR5
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:49:53 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:49:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16436910.1158616193629.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Clebert Suconic closed JBMESSAGING-525.
---------------------------------------

    Resolution: Done

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5, 1.2.0.Beta1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 17:57:48 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 17:57:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-302) Invoking
 Topic management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <25996999.1158616668477.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=comments#action_12343516 ] 
            
Clebert Suconic commented on JBMESSAGING-302:
---------------------------------------------

This is not a messaging Bug.
This is throw by the JMX console. As you can see there isn't any JMS code on the stack trace.

We could add an overload method without any parameters, but you can still have this exception if you don't set parameters on listMessagesNonDurableSub().


I didn't find any issues wih tlistMessagesDurableSub since all of its parameters are Strings.

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:05:49 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Mon, 18 Sep 2006 18:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1020) Replace direct
 uses of Log4J by JBoss logging.
In-Reply-To: <5738105.1157481328815.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7906061.1158617149164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1020?page=all ]

Chris Laprun reassigned JBPORTAL-1020:
--------------------------------------

    Assignee: Chris Laprun

> Replace direct uses of Log4J by JBoss logging.
> ----------------------------------------------
>
>                 Key: JBPORTAL-1020
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1020
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.4 Final, 2.2 Branch
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:05:49 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Mon, 18 Sep 2006 18:05:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1050) WSRP consumer
 will throw an
 NPE if the markup response from the producer is an empty string.
In-Reply-To: <9582939.1158614149445.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10258698.1158617149292.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1050?page=all ]

Chris Laprun resolved JBPORTAL-1050.
------------------------------------

    Resolution: Done

> WSRP consumer will throw an NPE if the markup response from the producer is an empty string.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1050
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1050
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:07:48 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 18:07:48 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <20582952.1158617268465.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Clebert Suconic closed JBMESSAGING-302.
---------------------------------------

    Fix Version/s:     (was: 1.0.1.CR5)
       Resolution: Won't Fix

Ovidiu,

Please reopen this issue if I am missing something..

Aas I said before, this exception is happening on the JMX console. I don't think we can do anything here.




> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:09:50 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 18 Sep 2006 18:09:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1034) prototype ldap
	in portal
In-Reply-To: <24023687.1158143023764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24383008.1158617390513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1034?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1034.
-------------------------------------------

    Resolution: Done

> prototype ldap in portal
> ------------------------
>
>                 Key: JBPORTAL-1034
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1034
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 1 week, 7 hours
>
> - define architecture, goals and roadmap for portal - ldap integration
> - prototype ApacheDS and OpenDS to use in portal for testing implementation of ldap integration

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:27:49 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:27:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-22) Nullify @In
 properties after end of invocation
Message-ID: <20455998.1158618469892.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-22?page=all ]

Gavin King closed JBSEAM-22.
----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

done. it was needed to make noisy transient declaration unnecessary

> Nullify @In properties after end of invocation
> ----------------------------------------------
>
>                 Key: JBSEAM-22
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-22
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Minor
>             Fix For: 1.1
>
>
> It may be desirable to nullify any injected dependencies when the invocation ends.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:33:50 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:33:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-352) debug.seam should be
 able to display interceptors for a given component
In-Reply-To: <27074460.1158165395733.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10633010.1158618830544.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-352?page=all ]

Gavin King closed JBSEAM-352.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

OK, just 'specially for you :)

> debug.seam should be able to display interceptors for a given component
> -----------------------------------------------------------------------
>
>                 Key: JBSEAM-352
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-352
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Stephan Bublava
>         Assigned To: Gavin King
>            Priority: Trivial
>             Fix For: 1.1
>
>
> It would be great, if debug.seam would display all interceptors that are enabled for a component. This just requires two getter methods for Component.interceptors and Component.clientSideInterceptors.
> I can deliver a patch if desired...

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:35:50 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 18 Sep 2006 18:35:50 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-526) JMSRedelivered
 flag not correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26822451.1158618950211.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Clebert Suconic updated JBMESSAGING-526:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:43:49 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:43:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-337) @Startup component
 with @Create is broken
In-Reply-To: <31262222.1156201658694.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11328172.1158619429860.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-337?page=all ]

Gavin King closed JBSEAM-337.
-----------------------------

    Resolution: Done

thanks, fixed now

> @Startup component with @Create is broken
> -----------------------------------------
>
>                 Key: JBSEAM-337
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-337
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Shane Bryzak
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>         Attachments: testcase.zip
>
>
> A component annotated with @Startup having a method annotated with @Create throws the following exception during deployment:
> 09:01:45,140 INFO  [Lifecycle] starting up: applicationContext
> 09:01:45,140 INFO  [Lifecycle] starting up: startupBean
> 09:01:45,156 ERROR [STDERR] java.lang.IllegalStateException: No active event context
> 09:01:45,156 ERROR [STDERR]     at org.jboss.seam.core.Manager.instance(Manager.java:320)
> 09:01:45,156 ERROR [STDERR]     at org.jboss.seam.interceptors.ConversationInterceptor.isMissingJoin(ConversationInterceptor.java:100)
> 09:01:45,156 ERROR [STDERR]     at org.jboss.seam.interceptors.ConversationInterceptor.endOrBeginLongRunningConversation(ConversationInterceptor.java:43)
> 09:01:45,156 ERROR [STDERR]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:45:49 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:45:49 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1039721.1158619549184.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=all ]

Gavin King closed JBSEAM-347.
-----------------------------

    Resolution: Won't Fix
      Assignee: Gavin King

According to the most recent comment, this issue appears to be "solved" on the user end.

> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>         Assigned To: Gavin King
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:47:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:47:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-136)
	@StartTask(pageFlow="...")
Message-ID: <15828302.1158619667648.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-136?page=all ]

Gavin King closed JBSEAM-136.
-----------------------------

    Resolution: Done
      Assignee: Gavin King

I understand that this problem was already fixed by a new jBPM release.

> @StartTask(pageFlow="...")
> --------------------------
>
>                 Key: JBSEAM-136
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-136
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: BPM
>            Reporter: Gavin King
>         Assigned To: Gavin King
>         Attachments: ToDo_jBPM_Example.zip
>
>
> There is no test for a pageflow attached to a task. A user reports that this is broken.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:47:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:47:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-339) Event scope
 container (WebRequestContext) doesn't clean the beans after destroy
In-Reply-To: <32055035.1156507726254.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <728205.1158619667777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-339?page=all ]

Gavin King updated JBSEAM-339:
------------------------------

    Issue Type: Feature Request  (was: Bug)
      Priority: Minor  (was: Critical)

This is not a bug and is not critical.

> Event scope container (WebRequestContext) doesn't clean the beans after destroy
> -------------------------------------------------------------------------------
>
>                 Key: JBSEAM-339
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-339
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1, 1.1
>         Environment: Jboss Seam nightly build 20060821, myfaces 1.1.4-SNAPSHOT from cvs. Tomahawk and tomahawk-snapshot 1.1.5-SNAPSHOT from cvs facelets 1.1.11
>            Reporter: German de la Cruz
>            Priority: Minor
>         Attachments: bulk.tar.gz, path_to_flush_beans.path
>
>
> Please, after the flushAndDestroyContext call, clean the destroyed bean from the event scope session (and therefore from the http request object. It produces a bug with tomahawk-sandbox and event scoped session bean. The destroyed beans are anyway invalid references and must be destroyed. 
> I've made a very simple patch, but anyway, it can't solve the problem since some modifications in tomahawk sandbox is needed. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:47:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:47:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBSEAM-339) Event scope
 container (WebRequestContext) doesn't clean the beans after destroy
In-Reply-To: <32055035.1156507726254.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28378873.1158619667946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-339?page=all ]

Gavin King reassigned JBSEAM-339:
---------------------------------

    Assignee: Gavin King

> Event scope container (WebRequestContext) doesn't clean the beans after destroy
> -------------------------------------------------------------------------------
>
>                 Key: JBSEAM-339
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-339
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1, 1.1
>         Environment: Jboss Seam nightly build 20060821, myfaces 1.1.4-SNAPSHOT from cvs. Tomahawk and tomahawk-snapshot 1.1.5-SNAPSHOT from cvs facelets 1.1.11
>            Reporter: German de la Cruz
>         Assigned To: Gavin King
>            Priority: Minor
>         Attachments: bulk.tar.gz, path_to_flush_beans.path
>
>
> Please, after the flushAndDestroyContext call, clean the destroyed bean from the event scope session (and therefore from the http request object. It produces a bug with tomahawk-sandbox and event scoped session bean. The destroyed beans are anyway invalid references and must be destroyed. 
> I've made a very simple patch, but anyway, it can't solve the problem since some modifications in tomahawk sandbox is needed. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:51:47 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:51:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-315) No control over the
 process definition when using components "taskInstanceListForType" &
 "pooledTaskInstanceList"
In-Reply-To: <13639447.1153515731332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <856385.1158619907914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-315?page=all ]

Gavin King closed JBSEAM-315.
-----------------------------

    Resolution: Won't Fix

Its perfectly fine to extend Seam with your own components for task lists. We don't need this in the Seam core.

> No control over the process definition when using components "taskInstanceListForType" & "pooledTaskInstanceList"
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-315
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-315
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: BPM
>    Affects Versions: 1.0.1
>            Reporter: Aravind Kumar
>
> There may be multiple Business Processes running in the same application. with CreateProcess annotation we can instantiate process instance for a particular process definition. 
> "taskInstanceListForType" & "pooledTaskInstanceList" components relies on TaskMgmtSession.java of JBPM to pull out  the taskinstances that the current user is authorized to see. But theres no control over the precess definition.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:53:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:53:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-335)
 NullPointerException if user
 quikcly decides to click a different link or button before the page renders
In-Reply-To: <7270828.1155764675359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27535611.1158620034491.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-335?page=all ]

Gavin King updated JBSEAM-335:
------------------------------

    Priority: Critical  (was: Major)

I have also observed this.

> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-335
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-335
>             Project: JBoss Seam
>          Issue Type: Bug
>         Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
>            Reporter: Keith Naas
>            Priority: Critical
>
> When a user is on one of our screens, they can decide to click a link before the next page loads.  Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181.  Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().  
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.  
> Stack Trace
> java.lang.NullPointerException
> 	at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> 	at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> 	at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> 	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> .....

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:53:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:53:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-319) s:link does not work
 after JBoss restart
In-Reply-To: <14926597.1153938371557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32998735.1158620034719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-319?page=all ]

Gavin King closed JBSEAM-319.
-----------------------------

    Resolution: Duplicate Issue

> s:link does not work after JBoss restart
> ----------------------------------------
>
>                 Key: JBSEAM-319
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-319
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1
>         Environment: jboss jems 4.0.4
> seam 1.1
>            Reporter: Chris Hane
>
> On a results screen I use the s:link tag in a table. The results screen is generated from a SFSB with ScopeType.EVENT. When the user clicks on the <s:link /> action, a new screen opens up from another SFSB with ScopeType.CONVERSATION.
> This works great until JBoss is restarted. Once restarted, the view action (below) on an existing results screen returns the results.xhtml screen without any records and does not seem to call the SFSB editor.view that I expected.
> See the thread for the full description.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:57:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:57:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-333) UI Labels and
 displaying the hash sign #
In-Reply-To: <13781486.1155680782986.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23478308.1158620274866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-333?page=all ]

Gavin King closed JBSEAM-333.
-----------------------------

    Resolution: Duplicate Issue

> UI Labels and displaying the hash sign #
> ----------------------------------------
>
>                 Key: JBSEAM-333
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-333
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, Tomcat 5.5.15, Embeddable EJB 3 (not sure which version exactly, but built on 6/2/2006), MyFaces 1.1.2
>            Reporter: zzzz8
>
> I can't seem to display the hash character
> In my JSP page, I have the following:
> <h:outputText escape="true" value="#{messages['TestNumber']}" />	
> In my messages.properties file, I have:
> TestNumber=Test #	
> Seam cannot evaluate the EL...
> Cannot get value for expression '#{messages['RequestNumber.Short']}'	
> I've also tried the Unicode character for the hash sign:
> TestNumber=Test \u0023	
> According to user raja05, the bug is due to code in Interpolator.interpolate which looks for a token after the hash sign - which in my case, is nonexistent since the hash sign is the last character in my label:
>       FacesContext context = FacesContext.getCurrentInstance();
>       StringTokenizer tokens = new StringTokenizer(string, "#{}", true);
>       StringBuilder builder = new StringBuilder(string.length());
>       while ( tokens.hasMoreTokens() )
>       {
>          String tok = tokens.nextToken();
>          if ( "#".equals(tok) )
>          {
>             String nextTok = tokens.nextToken();

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 18:59:53 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 18:59:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-100) Unify datasource
 configuration factory with E-EJB3
Message-ID: <14193285.1158620394011.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-100?page=all ]

Gavin King updated JBSEAM-100:
------------------------------

    Issue Type: Feature Request  (was: Bug)

> Unify datasource configuration factory with E-EJB3
> --------------------------------------------------
>
>                 Key: JBSEAM-100
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-100
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Trivial
>         Attachments: JBSEAM-100.zip
>
>
> The org.jboss.resource.adapter.jdbc.local.LocalTxDataSource does the same as org.jboss.seam.microcontainer.DataSourceFactory - they are slightly different in configuration only. 
> For example:
> - connectionUrl vs. connectionURL
> - getDatasource vs. getDataSource
> - etc.
> One internal difference is the CachedConnectionManager. It is injected into the LocalTxDataSource, but instantiated in the seam.microcontainer.DataSourceFactory.
> I think we should either unify, or better, kick out one of those two.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:01:53 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:01:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-348) IssueTracker example
 uses nonexisting annotation (Within)
In-Reply-To: <2204208.1157705731468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32988049.1158620513922.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-348?page=all ]

Gavin King closed JBSEAM-348.
-----------------------------

    Resolution: Done

Was already fixed

> IssueTracker example uses nonexisting annotation (Within)
> ---------------------------------------------------------
>
>                 Key: JBSEAM-348
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-348
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>            Reporter: Stephan Bublava
>            Priority: Trivial
>         Attachments: jbseam-348-patch.txt
>
>
> org/jboss/seam/example/issues/LoggedInInterceptor.java imports org.jboss.seam.annotations.Within, which does not exist (and is also never used in the 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

        


From jira-events at jboss.com  Mon Sep 18 19:05:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:05:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-312) seam dvd example -
 confirm.xhtml, 
 order.totalAmount have to be currentOrder.totalAmount
In-Reply-To: <23141316.1153224733923.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19704006.1158620754836.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-312?page=all ]

Gavin King closed JBSEAM-312.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done

thanks, fixed

> seam dvd example - confirm.xhtml, order.totalAmount have to be currentOrder.totalAmount
> ---------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-312
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-312
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Examples
>    Affects Versions: 1.0.1
>         Environment: JBoss 4.0.4 AS - Sun JDK 1.5.07
>            Reporter: Torsten Krah
>            Priority: Trivial
>             Fix For: 1.1
>
>   Original Estimate: 1 minute
>  Remaining Estimate: 1 minute
>
> In confirm.xhtml the el expression for totalamount needs to be currentOrder.totalAmount, not order.totalAmount.
> kind regards
> Torsten

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:19:52 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:19:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-309) Debug page throws
 LIE when viewing entity bean with lazy collection
In-Reply-To: <28104447.1152862331460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11151576.1158621592862.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-309?page=all ]

Gavin King closed JBSEAM-309.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

fixed

> Debug page throws LIE when viewing entity bean with lazy collection
> -------------------------------------------------------------------
>
>                 Key: JBSEAM-309
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-309
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Christian Bauer
>         Assigned To: Gavin King
>            Priority: Minor
>             Fix For: 1.1
>
>
> When I click on my logged in user variable in the Session context on the Seam debug page I get a LIE for a lazy collection in that user entity bean instance.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:21:55 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:21:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-279) Component lifetimes
 not guaranteed for SFSB backed components.
Message-ID: <15544864.1158621715280.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-279?page=all ]

Gavin King closed JBSEAM-279.
-----------------------------

    Resolution: Won't Fix

This is not a bug in Seam, it is merely an inconvenient set of defaults in EJB3 and Tomcat in JBoss AS. Please take this discussion elsewhere, since this issue report is not useful here.

> Component lifetimes not guaranteed for SFSB backed components.
> --------------------------------------------------------------
>
>                 Key: JBSEAM-279
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-279
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: ryan dewell
>
> Seam does not guarantee component lifecycles for SFSB backed components.  
> The container controls when SFSB's are removed / timed out.  When Seam accesses an SFSB that has been removed by the container, it results in an EJBNoSuchObjectException.
> The JBoss specific workaround for Session scoped components is to use the @CacheConfig annotation, setting the idle timeout to match the HttpSession timeout.  Similar changes would have to be made to any Conversation scoped component that uses a timeout greater than the default SFSB timeout of 5 minutes (which just happens to be the default timeout for Seam conversations).
> There is no workaround for Application scoped components.  Once removed by the container, EJBNoSuchObjectException's will continue to be thrown as Seam tries to access them.
> Seam's context model needs to somehow guarantee that its SFSB instances aren't removed by the container before Seam is finished with them.  And/or, it needs to recover from EJBNoSuchObjectException's more gracefully, especially with regards to Application scoped components for which there is no workaround.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:25:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:25:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-323) NPE when calling
 WebRemote method returning interface
In-Reply-To: <20944284.1153988831592.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17518683.1158621954662.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-323?page=all ]

Gavin King closed JBSEAM-323.
-----------------------------

    Resolution: Done

Closing this, because the immediate bug is fixed, and there is another issue for the second problem.

> NPE  when calling  WebRemote method returning interface
> -------------------------------------------------------
>
>                 Key: JBSEAM-323
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-323
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Remoting
>    Affects Versions: 1.1
>            Reporter: Michael Steiner
>         Assigned To: Shane Bryzak
>            Priority: Minor
>
> InterfaceGenerator calls  c = c.getSuperclass(); for interaces it is null than calls  !c.equals(Object.class) and this throws NullPointerException.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:25:55 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:25:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-270) Annotations
 @DataModelSelection
 and @DataModelSelectionIndex can't be used in one component together
Message-ID: <20662398.1158621955640.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-270?page=all ]

Gavin King updated JBSEAM-270:
------------------------------

    Issue Type: Feature Request  (was: Bug)
      Priority: Minor  (was: Major)

> Annotations @DataModelSelection and @DataModelSelectionIndex can't be used in one component together
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-270
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-270
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 1.0
>         Environment: WinXP Professional
> JBoss AS 4.0.4.GA (ejb3.deployer libs replaced by EJB3 RC8 libs)
> myFaces Core 1.1.3
> Tomahawk 1.1.3
> Facelets (as in Seam 1.0.0.GA)
> JDK1.5.0_06
>            Reporter: Jens Weintraut
>            Priority: Minor
>
> A seam component can't use both annotations @DataModelSelection and @DataModelSelectionIndex at once. If both are used deployment shows this error message:
> java.lang.IllegalStateException: Multiple @DataModelSelection fields for: messageList
> 	at org.jboss.seam.Component.initMembers(Component.java:533)
> 	at org.jboss.seam.Component.<init>(Component.java:199)
> 	at org.jboss.seam.Component.<init>(Component.java:159)
> 	at org.jboss.seam.Component.<init>(Component.java:154)
> 	at org.jboss.seam.Component.<init>(Component.java:149)
> 	at org.jboss.seam.init.Initialization.addComponent(Initialization.java:381)
> 	at org.jboss.seam.init.Initialization.addComponents(Initialization.java:343)
> 	at org.jboss.seam.init.Initialization.init(Initialization.java:195)
> 	at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:32)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729)
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:29:56 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-313) <s:validateAll> +
 facelets user tag
In-Reply-To: <22846419.1153495271497.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <216850.1158622196717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-313?page=all ]

Gavin King closed JBSEAM-313.
-----------------------------

    Resolution: Won't Fix

AFAIK, there is nothing I can do in Seam to fix this. It is a limit of facelets.

> <s:validateAll> + facelets user tag
> -----------------------------------
>
>                 Key: JBSEAM-313
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-313
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: jBoss 4.0.4.GA
> Seam 1.0.1.GA
>            Reporter: Denis Karpov
>         Attachments: test.zip
>
>
> =================================================
> *.xhtml file:
> --------------------
> .....
> <s:validateAll>
> 	<clv:edit id="edit" label="Test editable" value="#{test.obj.code}"/>  <!-- User defined tag inside validateAll-->
> </s:validateAll>
> .....
> ==================================================
> tag file:
> -----------------
> ....
> <ui:component 	xmlns="http://www.w3.org/1999/xhtml" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">
> 	<input id="#{id}" type="text" jsfc="h:inputText" value="#{value}"/>   <!--  Look at #{value} This is the root of problem -->
> </ui:component>
> ....
> =================================================
> Look at  value=#{value}
> Validation framework now can not process such binding that concerns facelets templateing.
> In attachment you will find simple working project. Just uncomment <!--s:validateAll--> and you will get exception.
> Exception:
> 19:07:19,921 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
> java.lang.RuntimeException: not an attribute value binding: #{value}
> 	at org.jboss.seam.ui.ModelValidator.validate(ModelValidator.java:30)
> 	at javax.faces.component._ComponentUtils.callValidators(_ComponentUtils.java:157)
> 	at javax.faces.component.UIInput.validateValue(UIInput.java:312)
> 	at javax.faces.component.UIInput.validate(UIInput.java:353)
> 	at javax.faces.component.UIInput.processValidators(UIInput.java:183)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIForm.processValidators(UIForm.java:70)
> 	at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:624)
> 	at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:146)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.processValidations(LifecycleImpl.java:262)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:35:54 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:35:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-343) Action method of
 source page being executed after destination action
In-Reply-To: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31390721.1158622554488.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-343?page=comments#action_12343544 ] 
            
Gavin King commented on JBSEAM-343:
-----------------------------------

Not so fast:

(1) The fix is no good, since if the page we are supposed to be rendering had a page action, it would not get called.
(2) Pages.callAction(FacesContext) actually updates the view-id, so your explanation for the cause of the behavior does not seem to be correct

> Action method of source page being executed after destination action
> --------------------------------------------------------------------
>
>                 Key: JBSEAM-343
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, jboss installation per Seam setup instructions
>            Reporter: Todd Main
>
> I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:
> Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".
>    <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>
> There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.
>                             <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
>                                 <f:param name="dayRange" value="7" />
>                                 <f:param name="documentCategory" value="po" />
>                                 #{quickClicksData.ordersFromLastSeven}
>                             </s:link>
> When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.
> Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:
> This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is
> Code:
>    
>    public boolean callPageActions(PhaseEvent event)
>    {
>       Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
>       boolean actionsWereCalled = false;
>       try
>       {
>          actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>          actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
>          return actionsWereCalled;
> The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.
> If the code were
> Code:
>     actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>     actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
>     return actionsWereCalled;
> 	
> that should fix this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:37:52 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Mon, 18 Sep 2006 19:37:52 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-343) Action method of
 source page being executed after destination action
In-Reply-To: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13380722.1158622672400.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-343?page=comments#action_12343545 ] 
            
Gavin King commented on JBSEAM-343:
-----------------------------------

Are you sure you have tested this against current CVS? If you have, I need a copy of your very simple test case.

> Action method of source page being executed after destination action
> --------------------------------------------------------------------
>
>                 Key: JBSEAM-343
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, jboss installation per Seam setup instructions
>            Reporter: Todd Main
>
> I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:
> Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".
>    <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>
> There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.
>                             <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
>                                 <f:param name="dayRange" value="7" />
>                                 <f:param name="documentCategory" value="po" />
>                                 #{quickClicksData.ordersFromLastSeven}
>                             </s:link>
> When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.
> Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:
> This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is
> Code:
>    
>    public boolean callPageActions(PhaseEvent event)
>    {
>       Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
>       boolean actionsWereCalled = false;
>       try
>       {
>          actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>          actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
>          return actionsWereCalled;
> The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.
> If the code were
> Code:
>     actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>     actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
>     return actionsWereCalled;
> 	
> that should fix this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:41:58 2006
From: jira-events at jboss.com (Todd Main (JIRA))
Date: Mon, 18 Sep 2006 19:41:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-343) Action method of
 source page being executed after destination action
In-Reply-To: <9607093.1157572109764.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14272299.1158622918468.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-343?page=comments#action_12343546 ] 
            
Todd Main commented on JBSEAM-343:
----------------------------------

I did test it against CVS at the time, as I was still using the CVS version then.  I don't have a simple test case right now, but I'll try to create one soon.

> Action method of source page being executed after destination action
> --------------------------------------------------------------------
>
>                 Key: JBSEAM-343
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-343
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: Windows XP, jboss installation per Seam setup instructions
>            Reporter: Todd Main
>
> I keep having trouble where the "from" page action seems be getting executed when using the <s:link> tag. Here's one example:
> Page "QuickClicks.xhtml" has a pages.xml entry with an action defined, so that the action gets called whenever I view "QuickClicks.xhtml".
>    <page view-id="/QuickClicks.xhtml" action="#{quickClicks.load}"/>
> There's an <s:link> on QuickClicks.xhtml that goes to a different session bean and displays a different xhtml page.
>                             <s:link target="reportResultsFrame" view-id="/Documents.xhtml" action="#{findDocuments.search}">
>                                 <f:param name="dayRange" value="7" />
>                                 <f:param name="documentCategory" value="po" />
>                                 #{quickClicksData.ordersFromLastSeven}
>                             </s:link>
> When I click the link, the quickClicks.load() method is being invoked AFTER findDocuments.search().   It should not be invoked at all, since I'm coming FROM that page, not TO it.
> Note: there is a posting in the Forum (see forum reference) that indicates a possible code fix for AbstractSeamPhaseListener.  Here is what was posted:
> This seems to be happening in AbstractPhaseListener and looks like a bug. The code in question is
> Code:
>    
>    public boolean callPageActions(PhaseEvent event)
>    {
>       Lifecycle.setPhaseId( PhaseId.INVOKE_APPLICATION );
>       boolean actionsWereCalled = false;
>       try
>       {
>          actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>          actionsWereCalled = Pages.instance().callAction() || actionsWereCalled;
>          return actionsWereCalled;
> The first "Pages.callAction(event.getFacesContext()) || actionsWereCalled " runs the intended action i.e. the action in the second page. Note that at this point, the view-id is still the first page as the lifecycle has not come into the "render" phase -- still in the "Execute" phase. Now that the method returned true, we are again invoking the Pages.instance().callAction() which calls the first view since the view-id is the first page. Thats the reason for the out of order of messages.
> If the code were
> Code:
>     actionsWereCalled = Pages.callAction( event.getFacesContext() ) || actionsWereCalled;
>     actionsWereCalled = actionsWereCalled || Pages.instance().callAction();
>     return actionsWereCalled;
> 	
> that should fix this.

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:43:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 18 Sep 2006 19:43:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-302) Invoking
 Topic management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <24951276.1158623034398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-302:
-----------------------------------------

      Assignee: Ovidiu Feodorov  (was: Clebert Suconic)
             

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Mon Sep 18 19:47:53 2006
From: jira-events at jboss.com (ryan dewell (JIRA))
Date: Mon, 18 Sep 2006 19:47:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-279) Component
 lifetimes not guaranteed for SFSB backed components.
Message-ID: <14053820.1158623273290.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-279?page=comments#action_12343547 ] 
            
ryan dewell commented on JBSEAM-279:
------------------------------------

Two different containers, interdependent, Seam and JBoss, each with their own idea about how long components should exist.  The fix lies in the configuration of one of those containers.  Changing the Jboss cache configuration is one of those solutions, the only solution so far presented in fact.

At the very least, if Seam as a component container truly considers this an "inconvenient set of defaults", then let's see the "convenient set of defaults" added to the Seam documentation.

> Component lifetimes not guaranteed for SFSB backed components.
> --------------------------------------------------------------
>
>                 Key: JBSEAM-279
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-279
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: ryan dewell
>
> Seam does not guarantee component lifecycles for SFSB backed components.  
> The container controls when SFSB's are removed / timed out.  When Seam accesses an SFSB that has been removed by the container, it results in an EJBNoSuchObjectException.
> The JBoss specific workaround for Session scoped components is to use the @CacheConfig annotation, setting the idle timeout to match the HttpSession timeout.  Similar changes would have to be made to any Conversation scoped component that uses a timeout greater than the default SFSB timeout of 5 minutes (which just happens to be the default timeout for Seam conversations).
> There is no workaround for Application scoped components.  Once removed by the container, EJBNoSuchObjectException's will continue to be thrown as Seam tries to access them.
> Seam's context model needs to somehow guarantee that its SFSB instances aren't removed by the container before Seam is finished with them.  And/or, it needs to recover from EJBNoSuchObjectException's more gracefully, especially with regards to Application scoped components for which there is no workaround.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:17:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:17:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-520) Messages
 received from
 Receiver.receive() using an XA are never deleted from the database if not
 withing a transactional boundary.
In-Reply-To: <23416910.1155654737451.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2460768.1158639474635.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-520?page=all ]

Ovidiu Feodorov closed JBMESSAGING-520.
---------------------------------------

    Resolution: Done

Modified an XASession to behave as a non-transactional session, unless associated with a global transaction. See http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3968696 for more details.

> Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-520
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>         Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
>            Reporter: Joel Lindheimer
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> Create a simple receiver, but do not place it within a Transaction boundary; shut down the server; look up the tables and you will see all the messages are still in the Messages and MessageRef tables.
> =========================================
> Observations using a debbuger reveal the following:
> =========================================
> Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method will always call createXAQueueSession() and create an XAQueconnection as transacted and Session.SESSION_TRANSACTED.  That being the case, non-XA Queues have no message-deletion problems with the current version (RC4) because the API removes all messages that are "not transacted and (!ack==1). I am guessing that using XA is problematic because the persistence layer is expecting manipulation of the transacted XASession--which for some reason is not working in this version of Messaging. More specifically, I suspect that when MDBs are tested you are not seeing this problem because the container is doing needed magic to manage the XASession transacted state, and therefore everything works fine therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver, there is something missing in the equation ergo the problems that I have been reporting regarding the ClickCommerce applications which use Receivers and not MDBs.  
> Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while waiting for a fix.

-- 
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

       



From jira-events at jboss.com  Tue Sep 19 00:17:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:17:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-410) java:/JmsXA in
 no-tx context does not work the same way as JBossMQ
Message-ID: <18565884.1158639474832.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-410?page=all ]

Ovidiu Feodorov closed JBMESSAGING-410.
---------------------------------------

    Resolution: Done

Modified an XASession to behave as a non-transactional session, unless associated with a global transaction.

> java:/JmsXA in no-tx context does not work the same way as JBossMQ
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-410
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-410
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR2
>            Reporter: Elias Ross
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>
> The same code I wrote that uses java:/JmsXA in a non-transacted environment with JBossMQ does not work with JBoss Messaging. And actually the same code does work correctly with SonicMQ as well, using the JCA adaptor with the Sonic XA connection factory.
> Why allow the use java:/JmsXA without transactions? It makes sense to use a cached connection manager anyway, like you would with a database. And anyway, should be addressed for compatibility.
> The following code *should* successfully send a message to a queue running without a transaction. Currently, it doesn't seem to do anything and no usage warnings are produced.
>       QueueConnectionFactory queueCF = (QueueConnectionFactory)new InitialContext.lookup("java:/JmsXA");
> ...
>       QueueConnection queueConnection = queueCF.createQueueConnection();
>       QueueSession queueSession =
>           queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
>       QueueSender queueSender = queueSession.createSender(queue);
>       ObjectMessage om = queueSession.createObjectMessage();
>       queueSender.send(om);
>       queueSender.close();
>       queueSession.close();
>       queueConnection.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

        


From jira-events at jboss.com  Tue Sep 19 00:25:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:25:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20421526.1158639955286.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Ovidiu Feodorov updated JBMESSAGING-541:
----------------------------------------

    Assignee: Ron Sigal  (was: Tom  Elrod)

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 19 00:25:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:25:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-277) Setting
 remoting lease period to -1 breaks ASF
Message-ID: <14471438.1158639955415.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-277?page=all ]

Ovidiu Feodorov closed JBMESSAGING-277.
---------------------------------------

    Resolution: Done
      Assignee: Ovidiu Feodorov  (was: Ron Sigal)

All TCK tests pass, so this is not an issue anymore.

> Setting remoting lease period to -1 breaks ASF
> ----------------------------------------------
>
>                 Key: JBMESSAGING-277
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-277
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Remoting
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> LeasePeriod == -1 is supposed to disable remoting leasing.
> However, setting LeasePeriod to -1 breaks ASF. TCK tests don't pass anymore.
> Whoever fixes this problem, should add a functional test so the Messaging testsuite catches this problem before TCK does.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:31:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:31:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13756078.1158640314198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov updated JBMESSAGING-542:
----------------------------------------

    Priority: Critical  (was: Major)

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:35:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:35:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-521)
 IllegalStateException:
 Cannot find delivery to cancel for 1000 Message test.
In-Reply-To: <6081093.1155659662294.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31184149.1158640555327.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-521?page=all ]

Ovidiu Feodorov closed JBMESSAGING-521.
---------------------------------------

    Resolution: Cannot Reproduce Bug

Closing as CR5 contains XAResource/global transaction handling changes, and I haven't been able to reproduce the race condition with the new code. If shows up again, please reopen and attach the relevant TRACE log.

> IllegalStateException: Cannot find delivery to cancel for 1000 Message test.
> ----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-521
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-521
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>         Environment: Windows XP, JBossServer4.0.4GA, Oracle10G 
>            Reporter: Joel Lindheimer
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>         Attachments: jboss.log.1, jboss.log.zip
>
>
> Receiver using XA within  a UserTransaction fails midway into 1000 message test.
> I am using the same receiver setup as in my previously logged bugs (aka all connections are
> newly retrieved within the boundary of the UserTransaction). 
> This same test succeeds:
> 1) Using a non-XA Receiver with no user transaction. 
> 2) Using an XA transaction but not within a UserTransaction boundary (however all Messages are not deleted from the messages table
> see: http://jira.jboss.com/jira/browse/JBMESSAGING-520).
> 08:48:22,968 ERROR [ExceptionUtil] SessionEndpoint[-2147483617] cancelDeliveries [5c4o722t-mzyxw2-eqwg7wan-1-eqwga5a0-1u]
> javax.jms.IllegalStateException: Cannot find delivery to cancel:-2147482831
>         at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.cancelDelivery(ServerConsumerEndpoint.java:566
> )
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.cancelDeliveries(ServerSessionEndpoint.java:476
> )
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionA
> dvised$cancelDeliveries$aop(SessionAdvised.java:131)
>         at sun.reflect.GeneratedMethodAccessor560.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate.cancelDeliveries(ClientSessionDelegate.java)
>         at org.jboss.jms.client.remoting.MessageCallbackHandler.close(MessageCallbackHandler.java:339)
>         at org.jboss.jms.client.container.ConsumerAspect.handleClosing(ConsumerAspect.java:116)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect25.invoke(ConsumerAspect25.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate.closing(ClientConsumerDelegate.java)
>         at org.jboss.jms.client.JBossMessageConsumer.close(JBossMessageConsumer.java:96)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.closeConsumer(JmsMessageConsumer.java:145)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.close(JmsMessageConsumer.java:76)
>         at org.springframework.jms.support.JmsUtils.closeMessageConsumer(JmsUtils.java:117)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.doReceiveAndExecute(DefaultMessage
> ListenerContainer.java:525)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:439)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:29,921 ERROR [RoundRobinPointToPointRouter] The receiver ConsumerEndpoint[-2147482548] is broken
> java.lang.ArithmeticException: / by zero
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.shiftTarget(RoundRobinPointToPointRoute
> r.java:218)
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.jav
> a:120)
>         at org.jboss.messaging.core.ChannelSupport.push(ChannelSupport.java:1676)
>         at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:693)
>         at org.jboss.messaging.core.ChannelSupport$InMemoryCallback.run(ChannelSupport.java:1518)
>         at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:33,328 ERROR [ExceptionUtil] SessionEndpoint[-2147483613] cancelDeliveries [5c4o722t-mzyxw2-eqwg7wan-1-e
> qwgad9s-1x]
> javax.jms.IllegalStateException: Cannot find delivery to cancel:-2147482386
>         at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.cancelDelivery(ServerConsumerEndpoint.java:566
> )
>         at org.jboss.jms.server.endpoint.ServerSessionEndpoint.cancelDeliveries(ServerSessionEndpoint.java:476
> )
>         at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionA
> dvised$cancelDeliveries$aop(SessionAdvised.java:131)
>         at sun.reflect.GeneratedMethodAccessor560.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate$cancelDeliveries_6592991528584912127.invokeNext
> (ClientSessionDelegate$cancelDeliveries_6592991528584912127.java)
>         at org.jboss.jms.client.delegate.ClientSessionDelegate.cancelDeliveries(ClientSessionDelegate.java)
>         at org.jboss.jms.client.remoting.MessageCallbackHandler.close(MessageCallbackHandler.java:339)
>         at org.jboss.jms.client.container.ConsumerAspect.handleClosing(ConsumerAspect.java:116)
>         at org.jboss.aop.advice.org.jboss.jms.client.container.ConsumerAspect25.invoke(ConsumerAspect25.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate$closing_4945873952494833124.invokeNext(ClientC
> onsumerDelegate$closing_4945873952494833124.java)
>         at org.jboss.jms.client.delegate.ClientConsumerDelegate.closing(ClientConsumerDelegate.java)
>         at org.jboss.jms.client.JBossMessageConsumer.close(JBossMessageConsumer.java:96)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.closeConsumer(JmsMessageConsumer.java:145)
>         at org.jboss.resource.adapter.jms.JmsMessageConsumer.close(JmsMessageConsumer.java:76)
>         at org.springframework.jms.support.JmsUtils.closeMessageConsumer(JmsUtils.java:117)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.doReceiveAndExecute(DefaultMessage
> ListenerContainer.java:525)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:439)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:34,125 ERROR [RoundRobinPointToPointRouter] The receiver ConsumerEndpoint[-2147482347] is broken
> java.lang.ArithmeticException: / by zero
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.shiftTarget(RoundRobinPointToPointRoute
> r.java:218)
>         at org.jboss.messaging.core.local.RoundRobinPointToPointRouter.handle(RoundRobinPointToPointRouter.jav
> a:120)
>         at org.jboss.messaging.core.ChannelSupport.push(ChannelSupport.java:1676)
>         at org.jboss.messaging.core.ChannelSupport.deliverInternal(ChannelSupport.java:693)
>         at org.jboss.messaging.core.ChannelSupport$DeliveryRunnable.run(ChannelSupport.java:1722)
>         at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,843 ERROR [ServerConnectionEndpoint] Exception occured
> javax.jms.IllegalStateException: Failed to acknowledge delivery null
>         at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.acknowledgeTransactionally(ServerConsumerEndpo
> int.java:485)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.processTransaction(ServerConnectionEndpoint.
> java:768)
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:380)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,859 ERROR [ServerConnectionEndpoint] Failed to rollback tx
> org.jboss.jms.util.MessagingTransactionRolledBackException: Transaction was rolled back.
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:391)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,875 ERROR [ExceptionUtil] ConnectionEndpoint[-2147483634] sendTransaction [5c4o722t-mzyxw2-eqwg7wan-1
> -eqwgam6j-21]
> org.jboss.jms.util.MessagingJMSException: Failed to rollback transaction after failure in prepare
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:396)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,875 ERROR [ExceptionInterceptor] Linked exception is:
> org.jboss.jms.util.MessagingTransactionRolledBackException: Transaction was rolled back.
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:391)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> 08:48:44,875 WARN  [TransactionImpl] XAException: tx=TransactionImpl:XidImpl[FormatId=257, GlobalId=jlindheime
> r/5614, BranchQual=, localId=5614] errorCode=XAER_RMERR
> org.jboss.jms.util.MessagingXAException: A Throwable was caught in sending the transaction
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:500)
>         at org.jboss.jms.tx.ResourceManager.prepare(ResourceManager.java:379)
>         at org.jboss.jms.tx.MessagingXAResource.prepare(MessagingXAResource.java:151)
>         at org.jboss.tm.TransactionImpl$Resource.prepare(TransactionImpl.java:2212)
>         at org.jboss.tm.TransactionImpl.prepareResources(TransactionImpl.java:1660)
>         at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:347)
>         at org.jboss.tm.TxManager.commit(TxManager.java:240)
>         at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:
> 140)
>         at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:787)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPl
> atformTransactionManager.java:539)
>         at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformT
> ransactionManager.java:509)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer.receiveAndExecute(DefaultMessageLi
> stenerContainer.java:453)
>         at com.cc.commons.jms.WMXDefaultMessageContainer102.receiveAndExecute(WMXDefaultMessageContainer102.ja
> va:28)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invoke
> Listener(DefaultMessageListenerContainer.java:823)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(De
> faultMessageListenerContainer.java:782)
>         at org.springframework.core.task.SimpleAsyncTaskExecutor$ConcurrencyThrottlingRunnable.run(SimpleAsync
> TaskExecutor.java:203)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: org.jboss.jms.util.MessagingJMSException: Failed to rollback transaction after failure in prepare
>         at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendTransaction(ServerConnectionEndpoint.jav
> a:396)
>         at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.org$jboss$jms$server$endpoint$advised$Conne
> ctionAdvised$sendTransaction$aop(ConnectionAdvised.java:99)
>         at sun.reflect.GeneratedMethodAccessor222.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
>         at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
>         at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
>         at org.jboss.aop.Advisor.dynamicInvoke(Advisor.java:723)
>         at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:101)
>         at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:126
> )
>         at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:999)
>         at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:98)
>         at org.jboss.remoting.Client.invoke(Client.java:612)
>         at org.jboss.remoting.Client.invoke(Client.java:604)
>         at org.jboss.jms.client.delegate.DelegateSupport.invoke(DelegateSupport.java:112)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:134)
>         at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:117)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:69)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N4986868250254447300.invokeN
> ext(ClientConnectionDelegate$sendTransaction_N4986868250254447300.java)
>         at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.jav
> a)
>         at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:491)
>         ... 16 more

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 00:37:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 00:37:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-287)
 RemotingTest.testConnectionListener() invalid
Message-ID: <16494440.1158640676646.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-287:
-------------------------------------------

    Assignee: Ovidiu Feodorov  (was: Ron Sigal)

> RemotingTest.testConnectionListener() invalid
> ---------------------------------------------
>
>                 Key: JBMESSAGING-287
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. 
> After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 01:59:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 01:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
Message-ID: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.test.messaging.jms.DurableSubscriberTest times out
------------------------------------------------------------

                 Key: JBMESSAGING-546
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.0.1.CR5




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 02:49:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 02:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-753) Leaving a
 Superstate does not record a NodeLog
In-Reply-To: <11880179.1158597657146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4189470.1158648541377.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-753?page=comments#action_12343553 ] 
            
Tom Baeyens commented on JBPM-753:
----------------------------------

holy moly... now i know why you didn't find this.  the issue i remembered was a different one.  

this one will be too hard to fix in 3.x, i think.  Probably 4.0 will have a better model for transforming logs from runtime data into usable data.

it should be possible to distill that from the current logs in one way or another, i think.  maybe it requires a few subsequent queries...

> Leaving a Superstate does not record a NodeLog
> ----------------------------------------------
>
>                 Key: JBPM-753
>                 URL: http://jira.jboss.com/jira/browse/JBPM-753
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM 3.1.2
>            Reporter: Britt Miner
>         Assigned To: Tom Baeyens
>
> Leaving a Superstate should persist a NodeLog, but doesn'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

        


From jira-events at jboss.com  Tue Sep 19 03:09:59 2006
From: jira-events at jboss.com (Sohui Gu (JIRA))
Date: Tue, 19 Sep 2006 03:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-347) Exception in
 PhaseListener
 RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
In-Reply-To: <13980918.1157614889801.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23610758.1158649799168.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-347?page=comments#action_12343554 ] 
            
Sohui Gu commented on JBSEAM-347:
---------------------------------

Thanks.I know how to solve this problem.sun reference implementation and myfaces cann't contain in lib at the same time.

> Exception in PhaseListener RENDER_RESPONSE(6) afterPhase when using Seam in Portlets
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-347
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-347
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>         Environment: JBoss 4.0.4 GA
> JBoss Portal 2.4
> MyFaces 1.1.3
>            Reporter: Maurice Zeijen
>         Assigned To: Gavin King
>            Priority: Critical
>
> I have been working on a way to get Seam working in a Portlet together with JSF and Facelets. After some hours of trying several stuff to get it all working together I thought I had the solution. But then the exception below got thrown. At first I thought that the problem was that I got the wrong value for the myFacesLifecycleBug property. But I tried true and false and both don't work. 
> My configuration details are below the exception.
> Code:
> 23:49:05,156 ERROR [PhaseListenerManager] Exception in PhaseListener RENDER_RESPONSE(6) afterPhase
> java.lang.IllegalStateException: No active session context
> 	at org.jboss.seam.Seam.isSessionInvalid(Seam.java:176)
> 	at org.jboss.seam.contexts.Lifecycle.endRequest(Lifecycle.java:235)
> 	at org.jboss.seam.jsf.SeamPortletPhaseListener.afterPhase(SeamPortletPhaseListener.java:87)
> 	at org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener.afterPhase(SeamExtendedMan
> agedPersistencePortletPhaseListener.java:53)
> 	at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(PhaseListenerManager
> .java:89)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:391)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:322)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.nonFacesRequest(MyFacesGenericPortlet.java:297)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:379)
> 	at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:265)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
> 	at com.smies.portlet.MyFacesGenericPortlet.render(MyFacesGenericPortlet.java:51)
> 	at org.jboss.portal.portlet.container.PortletContainer.invokeRender(PortletContainer.java:519)
> 	at org.jboss.portal.portlet.container.PortletContainer.dispatch(PortletContainer.java:440)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker$1.dispatch(PortletContainerInvoker.ja
> va:143)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.org$jboss$portal$core$aspects$portl
> et$TransactionInterceptor$invokeNotSupported$aop(TransactionInterceptor.java:85)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java:66)
> 	at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(TxInterceptor.java:101)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor$invokeNotSupported_4827075286966232
> 824.invokeNext(TransactionInterceptor$invokeNotSupported_4827075286966232824.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invokeNotSupported(TransactionInter
> ceptor.java)
> 	at org.jboss.portal.core.aspects.portlet.TransactionInterceptor.invoke(TransactionInterceptor.java:
> 55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.portlet.HeaderInterceptor.invoke(HeaderInterceptor.java:49)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ProducerCacheInterceptor.invoke(ProducerCacheIntercepto
> r.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ModesInterceptor.invoke(ModesInterceptor.java:59)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:45)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.WindowStatesInterceptor.invoke(WindowStatesInterceptor.
> java:55)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.PortletSessionSynchronizationInterceptor.invoke(Portlet
> SessionSynchronizationInterceptor.java:76)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$InvokeNextCommand.execute(
> ContextDispatcherInterceptor.java:124)
> 	at sun.reflect.GeneratedMethodAccessor245.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:104)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
> 	at org.jboss.portal.portlet.impl.spi.AbstractRequestContext.include(AbstractRequestContext.java:193
> )
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor$1.include(ContextDispatche
> rInterceptor.java:68)
> 	at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:84)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextDispatcherInterceptor.invoke(ContextDispatcherIn
> terceptor.java:74)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ContextTrackerInterceptor.invoke(ContextTrackerIntercep
> tor.java:50)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.SecureTransportInterceptor.invoke(SecureTransportInterc
> eptor.java:65)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ValveInterceptor.invoke(ValveInterceptor.java:61)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.container.PortletContainerInvoker.invoke(PortletContainerInvoker.java:1
> 14)
> 	at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy65.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.state.producer.StatefulPortletInvoker.invoke(StatefulPortletInvoker.jav
> a:249)
> 	at sun.reflect.GeneratedMethodAccessor233.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy67.invoke(Unknown Source)
> 	at org.jboss.portal.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerSe
> rvice.java:139)
> 	at org.jboss.portal.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvoker
> Service.java:155)
> 	at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy69.invoke(Unknown Source)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker$1.dispatch(TestPortletInvoker.java:63)
> 	at org.jboss.portal.portlet.invocation.PortletInvocation.dispatch(PortletInvocation.java:242)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.portlet.aspects.portlet.PortalSessionSynchronizationInterceptor.invoke(PortalSe
> ssionSynchronizationInterceptor.java:85)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.portlet.aspects.portlet.ConsumerCacheInterceptor.invoke(ConsumerCacheIntercepto
> r.java:93)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.model.instance.InstanceSecurityInterceptor.invoke(InstanceSecurityIntercep
> tor.java:83)
> 	at org.jboss.portal.portlet.invocation.PortletInterceptor.invoke(PortletInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.portlet.test.TestPortletInvoker.invoke(TestPortletInvoker.java:123)
> 	at sun.reflect.GeneratedMethodAccessor227.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> 	at $Proxy51.invoke(Unknown Source)
> 	at org.jboss.portal.core.impl.model.instance.InstanceImpl.invoke(InstanceImpl.java:273)
> 	at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:108)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:148)
> 	at org.jboss.portal.core.command.MarkupCommand.renderPortletWindow(MarkupCommand.java:463)
> 	at org.jboss.portal.core.command.RenderPageCommand.renderFragments(RenderPageCommand.java:76)
> 	at org.jboss.portal.core.command.MarkupCommand.execute(MarkupCommand.java:340)
> 	at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:91)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInte
> rceptor.java:171)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PageNavigationInterceptor.invoke(PageNavigationIntercep
> tor.java:80)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementIn
> terceptor.java:79)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java
> :59)
> 	at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:102)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:91)
> 	at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:78)
> 	at org.jboss.portal.core.CoreController.handle(CoreController.java:126)
> 	at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> 	at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> 	at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.ja
> va:142)
> 	at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> 	at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> 	at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> 	at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:287)
> 	at $Proxy161.handle(Unknown Source)
> 	at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:79)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:140)
> 	at org.jboss.portal.server.aspects.server.NavigationInterceptor.invoke(NavigationInterceptor.java:6
> 4)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java
> :65)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:74)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:174)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorIn
> terceptor.java:92)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.org$jboss$portal$core$aspects$server
> $TransactionInterceptor$invoke$aop(TransactionInterceptor.java:49)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> 	at org.jboss.aspects.tx.TxInterceptor$RequiresNew.invoke(TxInterceptor.java:275)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor$invoke_N5143606530999904530.invokeNe
> xt(TransactionInterceptor$invoke_N5143606530999904530.java)
> 	at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java)
> 	at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:37)
> 	at org.jboss.portal.common.invocation.Invocation.invokeNext(Invocation.java:130)
> 	at org.jboss.portal.common.invocation.Invocation.invoke(Invocation.java:171)
> 	at org.jboss.portal.server.servlet.PortalServlet.process(PortalServlet.java:294)
> 	at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:172)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202
> )
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> 	at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11Base
> Protocol.java:664)
> 	at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> 	at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> 	at java.lang.Thread.run(Thread.java:595)
> Here are the config files:
> Components.xml
> Code:
> <components>
>     <component name="org.jboss.seam.core.init">
>     	<property name="debug">true</property>
>         <property name="myFacesLifecycleBug">false</property>
>         <property name="jndiPattern">@jndiPattern@</property>
>     </component>
>     
>     <!-- 120 second conversation timeout -->
>     <component name="org.jboss.seam.core.manager">
>         <property name="conversationTimeout">120000</property>
>     </component>
>     
>     <component class="org.jboss.seam.core.Ejb" installed="@embeddedEjb@"/>
> </components>
> 	
> components.properties
> Code:
> embeddedEjb false
> jndiPattern TestPortlet/#{ejbName}/local
> 	
> faces-config.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE faces-config 
>     PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"
>     "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
> <faces-config>
> 	<!-- Navigation rules for the Booking demo app -->
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>view</from-outcome>
> 			<to-view-id>/view.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>edit</from-outcome>
> 			<to-view-id>/edit.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	
> 	<navigation-rule>
> 		<from-view-id>*</from-view-id>
> 		<navigation-case>
> 			<from-outcome>help</from-outcome>
> 			<to-view-id>/help.xhtml</to-view-id>
> 		</navigation-case>
> 	</navigation-rule>
> 	<application>
> 		<view-handler>
> 			com.sun.facelets.FaceletPortletViewHandler
> 		</view-handler>
> 	</application>
> 	<!-- Select one of the two standard persistence lifecycle models for the Seam application -->
> 	<lifecycle>
> 		<phase-listener>
> 			org.jboss.seam.jsf.SeamExtendedManagedPersistencePortletPhaseListener
> 		</phase-listener>
> 	</lifecycle>
> </faces-config>
> 	
> web.xml
> Code:
> <?xml version="1.0" encoding="UTF-8"?>
> <web-app> 
> 	 <!-- ### Seam  ######################################################################################
> ######### -->
>    
>     <listener>
>         <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>
>     </listener>
> 	
>     <!-- Propagate conversations across redirects -->
>     <filter>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <filter-class>org.jboss.seam.servlet.SeamRedirectFilter</filter-class>
>     </filter>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.seam</url-pattern>
>     </filter-mapping>
>     
>     <filter-mapping>
>         <filter-name>Seam Redirect Filter</filter-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </filter-mapping>
>     
>     <!-- ### JSF ########################################################################################
> ####### -->
>     
>     <context-param>
>         <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
>         <param-value>client</param-value>
>     </context-param>
>     <context-param>
>         <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
>         <param-value>.xhtml</param-value>
>     </context-param>
>     <context-param>
>         <param-name>facelets.DEVELOPMENT</param-name>
>         <param-value>true</param-value>
>     </context-param>
>     <servlet>
>         <servlet-name>Faces Servlet</servlet-name>
>         <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
>         <load-on-startup>1</load-on-startup>
>     </servlet>
> 	
> 	 <!-- ### MY FACES ###################################################################################
> ############ -->
>     
> 	
> 	<context-param>
> 		<param-name>org.apache.myfaces.ALLOW_JAVASCRIPT</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "true"
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.DETECT_JAVASCRIPT</param-name>
> 		<param-value>false</param-value>
> 		<description>
> 		    This parameter tells MyFaces if javascript code should be allowed in the
> 		    rendered HTML output.
> 		    If javascript is allowed, command_link anchors will have javascript code
> 		    that submits the corresponding form.
> 		    If javascript is not allowed, the state saving info and nested parameters
> 		    will be added as url parameters.
> 		    Default: "false"
> 	
> 		    Setting this param to true should be combined with STATE_SAVING_METHOD "server" for
> 		    best results.
> 	
> 		    This is an EXPERIMENTAL feature. You also have to enable the detector filter/filter mapping be
> low to get
> 		    JavaScript detection working.
> 		    </description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.PRETTY_HTML</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, rendered HTML code will be formatted, so that it is "human readable".
> 		    i.e. additional line separators and whitespace will be written, that do not
> 		    influence the HTML code.
> 		    Default: "true"
> 		</description>
> 	</context-param>
> 	<context-param>
> 		<param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
> 		<param-value>true</param-value>
> 		<description>
> 		    If true, a javascript function will be rendered that is able to restore the
> 		    former vertical scroll on every request. Convenient feature if you have pages
> 		    with long lists and you do not want the browser page to always jump to the top
> 		    if you trigger a link or button action that stays on the same page.
> 		    Default: "false"
> 		</description>
> 	</context-param>
>     <!-- Extensions Filter -->
> 	<filter>
> 		<filter-name>extensionsFilter</filter-name>
> 		<filter-class>org.apache.myfaces.component.html.util.ExtensionsFilter</filter-class>
> 		<init-param>
> 			<param-name>uploadMaxFileSize</param-name>
> 			<param-value>100m</param-value>
> 			<description>
> 				Set the size limit for uploaded files.
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 		<init-param>
> 			<param-name>uploadThresholdSize</param-name>
> 			<param-value>100k</param-value>
> 			<description>
> 				Set the threshold size - files below this limit are stored in memory, files above
> 				this limit are stored on disk.
> 	
> 				Format: 10 - 10 bytes
> 					10k - 10 KB
> 					10m - 10 MB
> 					1g - 1 GB
> 			</description>
> 		</init-param>
> 	</filter>
>     <!-- ### Faces Servlet Mapping  #####################################################################
> ########################## -->
>     
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.seam</url-pattern>
>     </servlet-mapping>
>     <servlet-mapping>
>         <servlet-name>Faces Servlet</servlet-name>
>         <url-pattern>*.xhtml</url-pattern>
>     </servlet-mapping>
> </web-app>
> 	
> The portlet implementation of the FaceletsViewHandler
> Code:
> package com.sun.facelets;
> import java.io.IOException;
> import javax.faces.FacesException;
> import javax.faces.application.ViewHandler;
> import javax.faces.context.ExternalContext;
> import javax.faces.context.FacesContext;
> import javax.faces.context.ResponseWriter;
> import javax.faces.render.RenderKit;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> /**
>  * ViewHandler implementation for Facelets used in Portlets
>  * 
>  */
> public class FaceletPortletViewHandler extends FaceletViewHandler {
> 	 public FaceletPortletViewHandler(ViewHandler parent) {
> 	        super(parent);
> 	    }
> 	    protected ResponseWriter createResponseWriter(FacesContext context)
> 	            throws IOException, FacesException {
> 	        ExternalContext extContext = context.getExternalContext();
> 	        RenderKit renderKit = context.getRenderKit();
> 	        RenderRequest request = (RenderRequest) extContext.getRequest();
> 	        RenderResponse response = (RenderResponse) extContext.getResponse();
> 	        String contenttype = request.getResponseContentType();
> 	        if (contenttype == null) {
> 	            contenttype = "text/html";
> 	        }
> 	        String encoding = response.getCharacterEncoding();
> 	        if (encoding == null) {
> 	            encoding = "ISO-8859-1";
> 	        }
> 	        ResponseWriter writer = renderKit.createResponseWriter(NullWriter.Instance, contenttype, en
> coding);
> 	        contenttype = writer.getContentType();
> 	        // apply them to the response
> 	        response.setContentType(contenttype);
> 	        // Now, clone with the real writer
> 	        writer = writer.cloneWithWriter(response.getWriter());
> 	        return writer;
> 	    }
> }
> 	
> Special version of the MyFaceGenericPortlet.
> Code:
> /**
>  * 
>  */
> package com.smies.portlet;
> import java.io.IOException;
> import java.util.Enumeration;
> import javax.portlet.PortletException;
> import javax.portlet.PortletMode;
> import javax.portlet.PortletSession;
> import javax.portlet.RenderRequest;
> import javax.portlet.RenderResponse;
> import javax.portlet.UnavailableException;
> /**
>  * 
>  */
> public class MyFacesGenericPortlet extends org.apache.myfaces.portlet.MyFacesGenericPortlet {
> 	private String viewPage = null;
> 	private String editPage = null;
> 	private String helpPage = null;
> 	
> 	public void init() throws UnavailableException, PortletException {
> 		viewPage = (String) this.getInitParameter("ViewPage");
> 		editPage = (String) this.getInitParameter("EditPage");
> 		helpPage = (String) this.getInitParameter("HelpPage");
> 		super.init();
> 	}
> 	
> 	public void render(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		PortletSession session = request.getPortletSession();
> 		PortletMode mode = (PortletMode) session
> 				.getAttribute("CurrentPortletMode");
> 		if (mode == null) {
> 			mode = request.getPortletMode();
> 		}
> 		if (mode != request.getPortletMode()) {
> 			request.setAttribute("isPortletModeChanged", Boolean.TRUE);
> 		} else {
> 			request.setAttribute("isPortletModeChanged", Boolean.FALSE);
> 		}
> 		session.setAttribute("CurrentPortletMode", mode);
> 		super.render(request, response);
> 	}
> 	
> 	protected void setDefaultView() throws UnavailableException {
>         this.defaultView = getPortletConfig().getInitParameter(DEFAULT_VIEW);
>         if (defaultView == null) {
>         	this.defaultView = this.viewPage;
>         }
>         if (defaultView == null) {
>             String msg = "Fatal2: must specify a JSF view id as the default view in portlet.xml";
>             throw new UnavailableException(msg);
>         }
>     }
> 	protected void doEdit(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, editPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> 	protected void doHelp(RenderRequest request, RenderResponse response)
> 			throws PortletException, IOException {
> 		Boolean isPortletModeChanged = (Boolean) request.getAttribute("isPortletModeChanged");
> 		if (isPortletModeChanged.booleanValue()) {
> 			setPortletRequestFlag(request);
> 			nonFacesRequest(request, response, helpPage);
> 			return;
> 		}
> 		facesRender(request, response);
> 	}
> }
> 	

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:04:59 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 04:04:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1187880.1158653099286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=comments#action_12343556 ] 
            
Ben Wang commented on JBCACHE-741:
----------------------------------

To run the GUI, do "run.bat" should kick start it. However, there is typo in
CLASSPATH=$CLASSPATH:./classes
It should be:
CLASSPATH=$CLASSPATH:./output/classes
instead.

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: jdom_example.tar
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:12:58 2006
From: jira-events at jboss.com (gunter zeilinger (JIRA))
Date: Tue, 19 Sep 2006 04:12:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2631)
 AttributePersistenceService should be started early
Message-ID: <24656519.1158653578660.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2631?page=comments#action_12343557 ] 
            
gunter zeilinger commented on JBAS-2631:
----------------------------------------

conf/jboss-service.xml provided by jems-installer-1.2.0.BETA2.jar does not include the AttributePersistenceService - and it is also not started by any other deploy/xxx-service.xml.

> AttributePersistenceService should be started early
> ---------------------------------------------------
>
>                 Key: JBAS-2631
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2631
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Dimitris Andreadis
>         Assigned To: Scott M Stark
>            Priority: Minor
>             Fix For: JBossAS-4.0.4.CR2
>
>
> When using the installer to create a full configuration the AttributePersistenceService is started through
> ./deploy/attrpm-service.xml.
> Now since this service needs to be present before any XMBean using it, it needs to be started earlier, probably throught conf/jboss-service.xml, as we do in the .zip distribution of jboss.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:17:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-68) Tidy-up JDBC classes
Message-ID: <7981584.1158653820355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mark Little reopened JBESB-68:
------------------------------

             

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:16:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:16:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-129) Wrong jar referred
 to in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10676237.1158653819756.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Mark Little reopened JBESB-129:
-------------------------------

             

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:16:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:16:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-129) Wrong jar referred
 to in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20534035.1158653819945.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Mark Little updated JBESB-129:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:17:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:17:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-129) Wrong jar referred to
 in Getting Started
In-Reply-To: <24822401.1155632057732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6561230.1158653820151.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-129?page=all ]

Mark Little closed JBESB-129.
-----------------------------

    Resolution: Done

> Wrong jar referred to in Getting Started
> ----------------------------------------
>
>                 Key: JBESB-129
>                 URL: http://jira.jboss.com/jira/browse/JBESB-129
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 1
> In the GettingStarted.doc
>  
> The recommended PostgreSQL is JDBC 2 EE 8.1 Build 407.  This version is available from the PostgreSQL JDBC website.
>  
> This refers to a .jar file that is NOT the one that ships with the Beta1.  Therefore it can lead to confusion when the reader is trying to tweak out their deployment.properties file as described on page 10.
>  
> At least the line above could say that while build 407 is recommended, we have provided pg74.216.jdbc2ee.jar in the conf/lib folder and you can use that one for testing purposes.  
>  
> Or something along those lines.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:18:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-68) Tidy-up JDBC classes
Message-ID: <12073635.1158653939709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mark Little updated JBESB-68:
-----------------------------

        Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                           (was: 4.0 Beta 1)
    Affects Version/s: 4.0 Beta 1
                           (was: 4.0 Alpha 1)

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:18:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:18:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-68) Tidy-up JDBC classes
Message-ID: <5034139.1158653939889.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-68?page=all ]

Mark Little closed JBESB-68.
----------------------------

    Resolution: Done

> Tidy-up JDBC classes
> --------------------
>
>                 Key: JBESB-68
>                 URL: http://jira.jboss.com/jira/browse/JBESB-68
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> - common\src\org\jboss\soa\esb\helpers\persist\JdbcCleanConn.java
> 1) Refactor
>     - rename to conventions
>     - categorize exceptions instead of using Exception
>     - group into a db specific package instead of persist
> - common\src\org\jboss\soa\esb\helpers\persist\SqlDbTable.java
> 1) Refactor
>     - rename to conventions    e.g getFldName - > getFieldName 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11124145.1158653940028.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Mark Little reopened JBESB-128:
-------------------------------

             

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19450735.1158653940297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Mark Little updated JBESB-128:
------------------------------

        Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                           (was: 4.0)
    Affects Version/s: 4.0 Beta 1
                           (was: 4.0)

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30607186.1158653940164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment:     (was: jdom_example.tar)

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-128) Redundant XDoclet
 Information in Documentation
In-Reply-To: <30378377.1155564977482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16880300.1158653940422.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-128?page=all ]

Mark Little closed JBESB-128.
-----------------------------

    Resolution: Done

> Redundant XDoclet Information in Documentation
> ----------------------------------------------
>
>                 Key: JBESB-128
>                 URL: http://jira.jboss.com/jira/browse/JBESB-128
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Jason Lenhart
>         Assigned To: Jason Lenhart
>            Priority: Minor
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> Does the XDoclet configuration information still need to be in the documentation now that EJB3 is in use - validate and remove.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8539477.1158653940890.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little reopened JBESB-137:
-------------------------------

             

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20601252.1158653941062.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little updated JBESB-137:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:19:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-137) Race condition in
	GPListener
In-Reply-To: <14152240.1158232777534.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17632296.1158653941289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-137?page=all ]

Mark Little closed JBESB-137.
-----------------------------

    Resolution: Done

> Race condition in GPListener
> ----------------------------
>
>                 Key: JBESB-137
>                 URL: http://jira.jboss.com/jira/browse/JBESB-137
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11719840.1158654061495.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little reopened JBESB-112:
-------------------------------

             

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24323480.1158654061693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little updated JBESB-112:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-112) check javadocs rule
	in build.xml
In-Reply-To: <14317489.1154531771360.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23964205.1158654062033.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-112?page=all ]

Mark Little closed JBESB-112.
-----------------------------

    Resolution: Done

> check javadocs rule in build.xml
> --------------------------------
>
>                 Key: JBESB-112
>                 URL: http://jira.jboss.com/jira/browse/JBESB-112
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7608995.1158654062421.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-132?page=all ]

Mark Little updated JBESB-132:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:21:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14983725.1158654062855.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-130?page=all ]

Mark Little updated JBESB-130:
------------------------------

    Fix Version/s: 4.0 Beta 1 Maintenance Pack 1
                       (was: 4.0)

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:23:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-139) Add in ftp support
Message-ID: <25718589.1158654181382.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add in ftp support
------------------

                 Key: JBESB-139
                 URL: http://jira.jboss.com/jira/browse/JBESB-139
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation, ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Esteban Schifman
             Fix For: 4.0 Beta 1 Maintenance Pack 1




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:23:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 04:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21328235.1158654181524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment: jdom_example.tar

Latest update to fix the run.sh and run.bat.

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: jdom_example.tar
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:42:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:42:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10196429.1158655379568.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-132?page=comments#action_12343561 ] 
            
Mark Little commented on JBESB-132:
-----------------------------------

Can the trailblazer be built from an installed (binary only) distribution of JBossESB?

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 04:46:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 04:46:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18263958.1158655618097.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-130?page=comments#action_12343562 ] 
            
Mark Little commented on JBESB-130:
-----------------------------------

The trunk definitely shouldn't be there. But the product folder is at the root of our svn and not part of the actual shipped source. The trailblazer needs to be able to be built from the shipped source (you can see what that looks like from http://labs.jboss.com/file-access/default/members/jbossesb/downloads/4.0Beta1/src/jbossesb-4.0Beta1-src.zip) and the shipped binary (http://labs.jboss.com/file-access/default/members/jbossesb/downloads/4.0Beta1/binary/jbossesb-4.0Beta1.zip).

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:12:01 2006
From: jira-events at jboss.com (srk (JIRA))
Date: Tue, 19 Sep 2006 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3667) HotSpot Crashes
Message-ID: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>

HotSpot Crashes
---------------

                 Key: JBAS-3667
                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Build System
    Affects Versions: JBossAS-4.0.4.GA
         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
            Reporter: srk
         Assigned To: Ruel Loehr
            Priority: Blocker
         Attachments: hs_err_pid7517.log

When I start JBoss it crashes with the following hs-errpid*.log file generated..
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x3b514a]
#

---------------  T H R E A D  ---------------

Current thread (0x9d418f38):  VMThread [id=7520]

siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400

Registers:
EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206

Top of Stack: (sp=0x9d3ff230)
0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 

Instructions: (pc=0xb6ed014a)
0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 

Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x3b514a]
V  [libjvm.so+0x3dde6e]
V  [libjvm.so+0x3b5332]
V  [libjvm.so+0x422efe]
V  [libjvm.so+0x42220e]
V  [libjvm.so+0x421e97]
V  [libjvm.so+0x4bb2af]
V  [libjvm.so+0x4baca6]
V  [libjvm.so+0x4ba317]
V  [libjvm.so+0x4ba525]
V  [libjvm.so+0x4ba130]
V  [libjvm.so+0x3eca78]
C  [libpthread.so.0+0x4dac]

VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0


---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
  0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
  0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
  0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
  0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
  0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
  0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
  0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
  0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
  0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
  0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
  0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
  0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
  0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
  0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
  0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
  0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
  0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
  0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
  0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
  0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
  0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
  0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
  0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
  0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
  0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]

Other Threads:
=>0x9d418f38 VMThread [id=7520]
  0x9d42add8 WatcherThread [id=7528]

VM state:at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
[0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
[0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0

Heap
 PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
  eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
  from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
  to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
 PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
  object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
 PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
  object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)

Dynamic libraries:
08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java


VM Arguments:
jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
java_command: org.jboss.Main

Environment Variables:
JAVA_HOME=/usr/java/jdk1.5.0_03/
PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
SHELL=/bin/bash


---------------  S Y S T E M  ---------------

OS:Red Hat Enterprise Linux ES release 3 (Taroon)

uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
libc:glibc 2.3.2 NPTL 0.60 
rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
load average:1.08 0.25 0.08

CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht

Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)

vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)



-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:12:01 2006
From: jira-events at jboss.com (srk (JIRA))
Date: Tue, 19 Sep 2006 05:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3667) HotSpot Crashes
In-Reply-To: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19390483.1158657121880.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

srk updated JBAS-3667:
----------------------

    Attachment: hs_err_pid7517.log

Here is the log file attached.

> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>         Assigned To: Ruel Loehr
>            Priority: Blocker
>         Attachments: hs_err_pid7517.log
>
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:12:04 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 05:12:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3399) Transaction timeout
	fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10315856.1158657124524.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3399?page=all ]

Adrian Brock closed JBAS-3399.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Adrian Brock)

Its only going to throw an error if you access a transacted resource
or you test yourself whether the transaction timed out.

> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:39:01 2006
From: jira-events at jboss.com (tbech (JIRA))
Date: Tue, 19 Sep 2006 05:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3399) Transaction
 timeout fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7135728.1158658741212.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3399?page=comments#action_12343565 ] 
            
tbech commented on JBAS-3399:
-----------------------------

>>  Its only going to throw an error if you access a transacted resource 
and
>> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
>> a) throw an error after timeout 

What I was saying is:
for long transaction - (lets say 10000 gueries/updates, one after another), the exception is not thrown until commit (and the transacted resource is used all the time in this transaction).
This is a bug, (and you agree - "Its only going to throw an error if you access a transacted resource ", but it doesn't throw an exception). So why rejected?


> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:42:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 05:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3667) HotSpot Crashes
In-Reply-To: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19590572.1158658921331.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

Adrian Brock closed JBAS-3667.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Ruel Loehr)

Ruel. These are not JBoss bug. It is a Sun bug.
The error is a seg fault in the garbage collector.

If we let you open such a (non-JBoss) bug report, 
there will be a stream of user bug reports that are the same.

We do not want this.

> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>            Priority: Blocker
>         Attachments: hs_err_pid7517.log
>
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 05:45:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 05:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3399) Transaction
 timeout fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10374732.1158659101079.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3399?page=comments#action_12343567 ] 
            
Adrian Brock commented on JBAS-3399:
------------------------------------

The use the JBossTM plugin instead of JBossJTA which rollsback the transaction
at transaction timeout.

And please use the forums instead of bug reports to ask for help.

> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:00:01 2006
From: jira-events at jboss.com (Tomaz Cerar (JIRA))
Date: Tue, 19 Sep 2006 06:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-429) Support for
 external security systems
Message-ID: <7019780.1158660001449.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-429?page=comments#action_12343570 ] 
            
Tomaz Cerar commented on JBPM-429:
----------------------------------

is it possible to get this fix ready for 3.1.3 or at least 3.2?

> Support for external security systems
> -------------------------------------
>
>                 Key: JBPM-429
>                 URL: http://jira.jboss.com/jira/browse/JBPM-429
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.0
>         Environment: NA
>            Reporter: Ashwini Kumar
>         Assigned To: Tom Baeyens
>   Original Estimate: 2 minutes
>  Remaining Estimate: 2 minutes
>
> Please change the readAssignmentDelegation method in org.jbpm.jpdl.xml.JpdlXmlReader    to be the following.
> The original method would ignore the class attribute assigned to swimlane assignments and default it to org.jbpm.identity.assignment.ExpressionAssignmentHandler
> Thanks,
> private Delegation readAssignmentDelegation(Element assignmentElement) {
>     Delegation assignmentDelegation = new Delegation();
>     String expression = assignmentElement.attributeValue("expression");
>     if (expression!=null) {
>       assignmentDelegation.setProcessDefinition(processDefinition);
>       String assignmentHandler = assignmentElement.attributeValue("class");
>       if (assignmentHandler != null){
> 		assignmentDelegation.setClassName(assignmentHandler);
>       }
>       else{
> 		assignmentDelegation.setClassName("org.jbpm.identity.assignment.ExpressionAssignmentHandler");	
>       }
>       assignmentDelegation.setConfiguration("<expression>"+expression+"</expression>");
>       
>     } else {
>       assignmentDelegation.read(assignmentElement, this);
>     }
>     return assignmentDelegation;
>   }

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:18:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 06:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33471433.1158661081426.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment:     (was: jdom_example.tar)

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:22:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 19 Sep 2006 06:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-741) Create a jdom
 replication GUI example
In-Reply-To: <20963955.1156085711482.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18671275.1158661321225.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-741?page=all ]

Ben Wang updated JBCACHE-741:
-----------------------------

    Attachment: jdom_example.tar

> Create a jdom replication GUI example
> -------------------------------------
>
>                 Key: JBCACHE-741
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-741
>             Project: JBoss Cache
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>         Attachments: jdom_example.tar
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> We will need to have a JDOM gui that can demonstrate the fine-grained replication using the "aspectized" jdom library.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 06:39:01 2006
From: jira-events at jboss.com (srk (JIRA))
Date: Tue, 19 Sep 2006 06:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3667) HotSpot Crashes
In-Reply-To: <6628627.1158657121591.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18395547.1158662341787.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

srk reopened JBAS-3667:
-----------------------

             

> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Build System
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>            Priority: Blocker
>         Attachments: hs_err_pid7517.log
>
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 07:37:54 2006
From: jira-events at jboss.com (Mladen Turk (JIRA))
Date: Tue, 19 Sep 2006 07:37:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5891076.1158665874689.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343573 ] 
            
Mladen Turk commented on JBAS-3495:
-----------------------------------

Can someone point me to the place in the source both inside run.jar and shutdown.jar
where optional native .dll can be called as singleton.
This dll will allow together with jbosssvc.exe thread dumps either to the stdout (well stdout.log in service mode)
or to a specified file.

The reason why it is needed in shutdown.jar is to emulate the CTRL+C.

The code that needs to be added is very simple and does noting if the dll is not found,
which is not the case for service mode since both jbosssvc.exe and jbosssch.dll will
be present is that case.

The beauty is that the run.bat is used for service, which means there is no additional
leaning curve for service mode, like there is for other service wrappers.
The overhead of 3MB per service, for an additional cmd.exe is acceptable thought.



> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 07:41:55 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Tue, 19 Sep 2006 07:41:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-3667) HotSpot Crashes
Message-ID: <30011937.1158666115398.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3667?page=all ]

Adrian Brock deleted JBAS-3667:
-------------------------------


> HotSpot Crashes
> ---------------
>
>                 Key: JBAS-3667
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3667
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: OS:Red Hat Enterprise Linux ES release 3 (Taroon) , Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86
>            Reporter: srk
>            Priority: Blocker
>
> When I start JBoss it crashes with the following hs-errpid*.log file generated..
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> #  SIGSEGV (0xb) at pc=0xb6ed014a, pid=7517, tid=2638216112
> #
> # Java VM: Java HotSpot(TM) Server VM (1.5.0_03-b07 mixed mode)
> # Problematic frame:
> # V  [libjvm.so+0x3b514a]
> #
> ---------------  T H R E A D  ---------------
> Current thread (0x9d418f38):  VMThread [id=7520]
> siginfo:si_signo=11, si_errno=0, si_code=1, si_addr=0x00000400
> Registers:
> EAX=0xb1000f08, EBX=0xb7078b2c, ECX=0x9d806d48, EDX=0x9d806d74
> ESP=0x9d3ff230, EBP=0x9d3ff238, ESI=0x00000400, EDI=0xb1004a74
> EIP=0xb6ed014a, CR2=0x00000400, EFLAGS=0x00010206
> Top of Stack: (sp=0x9d3ff230)
> 0x9d3ff230:   b7078b2c b1000f08 9d3ff268 b6ef8e6e
> 0x9d3ff240:   b1000f08 b708706c 9d3ff268 b6ef8e21
> 0x9d3ff250:   9ea5a0ac b0f336d0 9ea5b804 b7078b2c
> 0x9d3ff260:   b706a140 b708706c 9d3ff288 b6ed0332
> 0x9d3ff270:   9d80a810 b0ffae28 b7077120 b6ed02fa
> 0x9d3ff280:   b7078b2c b708706c 9d3ff318 b6f3defe
> 0x9d3ff290:   b708706c 00000000 00000001 9d3ff2b8
> 0x9d3ff2a0:   b7503dfd b75c8660 0000baa8 9d3ff2c0 
> Instructions: (pc=0xb6ed014a)
> 0xb6ed013a:   00 00 00 5b 81 c3 ef 89 1a 00 8b 30 85 f6 74 45
> 0xb6ed014a:   8b 06 83 e0 03 83 f8 03 74 3b 8b 16 c7 06 03 00 
> Stack: [0x9d37f000,0x9d400000),  sp=0x9d3ff230,  free space=512k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x3b514a]
> V  [libjvm.so+0x3dde6e]
> V  [libjvm.so+0x3b5332]
> V  [libjvm.so+0x422efe]
> V  [libjvm.so+0x42220e]
> V  [libjvm.so+0x421e97]
> V  [libjvm.so+0x4bb2af]
> V  [libjvm.so+0x4baca6]
> V  [libjvm.so+0x4ba317]
> V  [libjvm.so+0x4ba525]
> V  [libjvm.so+0x4ba130]
> V  [libjvm.so+0x3eca78]
> C  [libpthread.so.0+0x4dac]
> VM_Operation (0x9cc52e8c): parallel gc system gc, mode: safepoint, requested by thread 0x9d44bba0
> ---------------  P R O C E S S  ---------------
> Java Threads: ( => current thread )
>   0x9a528258 JavaThread "HSQLDB Timer @39859" daemon [_thread_blocked, id=7547]
>   0x9c2b30c0 JavaThread "WorkManager(3)-1" daemon [_thread_blocked, id=7546]
>   0x99407a98 JavaThread "Thread-3" daemon [_thread_blocked, id=7545]
>   0x9a9cc3d0 JavaThread "JBossMQ Cache Reference Softner" daemon [_thread_blocked, id=7544]
>   0x9a3dfcd0 JavaThread "SubscriptionWatchDog" [_thread_blocked, id=7543]
>   0x082481a8 JavaThread "ContainerBackgroundProcessor[StandardEngine[jboss.web]]" daemon [_thread_blocked, id=7542]
>   0x9b17f900 JavaThread "PooledInvokerAcceptor#0-4445" [_thread_in_native, id=7541]
>   0x9be2a548 JavaThread "RMI TCP Accept-4444" daemon [_thread_in_native, id=7540]
>   0x9b133e78 JavaThread "TimeoutFactory-0" daemon [_thread_blocked, id=7539]
>   0x9afea8c0 JavaThread "JBoss System Threads(1)-2" daemon [_thread_in_native, id=7538]
>   0x9be5e778 JavaThread "GC Daemon" daemon [_thread_blocked, id=7537]
>   0x9be5ddc0 JavaThread "RMI Reaper" [_thread_blocked, id=7536]
>   0x9adf2570 JavaThread "Timer-1" daemon [_thread_blocked, id=7535]
>   0x9bef60a0 JavaThread "RMI TCP Accept-1098" daemon [_thread_in_native, id=7534]
>   0x087179c8 JavaThread "JBoss System Threads(1)-1" daemon [_thread_in_native, id=7533]
>   0x08154638 JavaThread "ScannerThread" daemon [_thread_blocked, id=7532]
>   0x08650da0 JavaThread "Timer-0" daemon [_thread_blocked, id=7531]
>   0x9d44c6c8 JavaThread "DestroyJavaVM" [_thread_blocked, id=7517]
>   0x9d44bba0 JavaThread "main" [_thread_blocked, id=7529]
>   0x9d4298c8 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=7527]
>   0x9d428528 JavaThread "CompilerThread1" daemon [_thread_blocked, id=7526]
>   0x9d4275e8 JavaThread "CompilerThread0" daemon [_thread_blocked, id=7525]
>   0x9d426678 JavaThread "AdapterThread" daemon [_thread_blocked, id=7524]
>   0x9d4257f0 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=7523]
>   0x9d41c318 JavaThread "Finalizer" daemon [_thread_blocked, id=7522]
>   0x9d41b6d8 JavaThread "Reference Handler" daemon [_thread_blocked, id=7521]
> Other Threads:
> =>0x9d418f38 VMThread [id=7520]
>   0x9d42add8 WatcherThread [id=7528]
> VM state:at safepoint (normal execution)
> VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
> [0x0805a510/0x0805a538] Threads_lock - owner thread: 0x9d418f38
> [0x0805a960/0x0805a978] Heap_lock - owner thread: 0x9d44bba0
> Heap
>  PSYoungGen      total 19456K, used 4556K [0xafb30000, 0xb17a0000, 0xb17a0000)
>   eden space 9792K, 0% used [0xafb30000,0xafb30000,0xb04c0000)
>   from space 9664K, 47% used [0xb0e30000,0xb12a3138,0xb17a0000)
>   to   space 9664K, 0% used [0xb04c0000,0xb04c0000,0xb0e30000)
>  PSOldGen        total 233024K, used 19194K [0xa17a0000, 0xafb30000, 0xafb30000)
>   object space 233024K, 8% used [0xa17a0000,0xa2a5e998,0xafb30000)
>  PSPermGen       total 20096K, used 19991K [0x9d7a0000, 0x9eb40000, 0xa17a0000)
>   object space 20096K, 99% used [0x9d7a0000,0x9eb25c50,0x9eb40000)
> Dynamic libraries:
> 08048000-08056000 r-xp 00000000 08:11 15925290   /usr/java/jdk1.5.0_03/bin/java
> VM Arguments:
> jvm_args: -Xms256m -Xmx256m -Dprogram.name=run.sh -Djava.endorsed.dirs=/home/jboss/jboss-4.0.4/lib/endorsed
> java_command: org.jboss.Main
> Environment Variables:
> JAVA_HOME=/usr/java/jdk1.5.0_03/
> PATH=/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/jboss/bin:/usr/java/jdk1.5.0_03//bin
> LD_LIBRARY_PATH=/usr/java/jdk1.5.0_03/jre/lib/i386/server:/usr/java/jdk1.5.0_03/jre/lib/i386:/usr/java/jdk1.5.0_03/jre/../lib/i386:/usr/local/lib/
> SHELL=/bin/bash
> ---------------  S Y S T E M  ---------------
> OS:Red Hat Enterprise Linux ES release 3 (Taroon)
> uname:Linux 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
> libc:glibc 2.3.2 NPTL 0.60 
> rlimit: STACK 10240k, CORE 0k, NPROC 7168, NOFILE 1024, AS infinity
> load average:1.08 0.25 0.08
> CPU:total 2 family 15, cmov, cx8, fxsr, mmx, sse, sse2, ht
> Memory: 4k page, physical 2053540k(1281952k free), swap 2040244k(2040244k free)
> vm_info: Java HotSpot(TM) Server VM (1.5.0_03-b07) for linux-x86, built on Apr 13 2005 02:09:32 by java_re with gcc 3.2.1-7a (J2SE release)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 07:47:57 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 19 Sep 2006 07:47:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11615610.1158666477221.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343575 ] 
            
Dimitris Andreadis commented on JBAS-3495:
------------------------------------------

You mean?

system/src/main/org/jboss/Main.java

server/scr/main/org/jboss/Shutdown.java
(this one remotely tells the server to shutdown)

> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:41:56 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:41:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-82) Release CR7 that
 aligns with AS 4.0.5.GA
Message-ID: <5411313.1158669716890.JavaMail.jira@cloud.prod.atl2.jboss.com>

Release CR7 that aligns with AS 4.0.5.GA
----------------------------------------

                 Key: JBXB-82
                 URL: http://jira.jboss.com/jira/browse/JBXB-82
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Task
            Reporter: Heiko Braun


JBossWS has a dependency on it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:43:55 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:43:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-83) XOPIncludeHandler
 should not work on InputStreams
Message-ID: <16784397.1158669835189.JavaMail.jira@cloud.prod.atl2.jboss.com>

XOPIncludeHandler should not work on InputStreams
-------------------------------------------------

                 Key: JBXB-83
                 URL: http://jira.jboss.com/jira/browse/JBXB-83
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
            Reporter: Heiko Braun


The XOPInclude works on ObjectInputStreams. This disaalows paasing thorugh XB to JBossWS. AFAIK that code piece is obsolete and can be removed.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:45:55 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Tue, 19 Sep 2006 08:45:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3668) EJB Deployment and
	Lookup
Message-ID: <10929330.1158669955877.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB Deployment and Lookup
-------------------------

                 Key: JBAS-3668
                 URL: http://jira.jboss.com/jira/browse/JBAS-3668
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.CR2
            Reporter: madan srinivas
         Assigned To: Bill Burke


I have used JBoss 4.0.4 CR2 and deployed EJB3.0 Entity bean and stateless session bean

Below is the deployed status : 

17:09:11,297 INFO  [JmxKernelAbstraction] installing MBean: persistence.units:ja
r=Test.jar,unitName=manager1 with dependencies:
17:09:11,297 INFO  [JmxKernelAbstraction]       jboss.jca:name=MSSQLDS,service=M
anagedConnectionFactory
17:09:11,344 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Test.
jar,name=FileDetailsClientBean,service=EJB3 with dependencies:
17:09:11,344 INFO  [JmxKernelAbstraction]       persistence.units:jar=Test.jar,u
nitName=manager1
17:09:11,344 INFO  [EJB3Deployer] Deployed: file:/D:/jboss-4.0.4.CR2/server/defa
ult/deploy/Test.jar


But i get following message on jboss server : 

--- MBeans waiting for other MBeans ---
ObjectName: persistence.units:jar=Test.jar,unitName=manager1
  State: NOTYETINSTALLED
  I Depend On:
    jboss.jca:name=MSSQLDS,service=ManagedConnectionFactory
  Depends On Me:
    jboss.j2ee:jar=Test.jar,name=FileDetailsClientBean,service=EJB3

ObjectName: jboss.j2ee:jar=Test.jar,name=FileDetailsClientBean,service=EJB3
  State: NOTYETINSTALLED
  I Depend On:
    persistence.units:jar=Test.jar,unitName=manager1

--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: jboss.jca:name=MSSQLDS,service=ManagedConnectionFactory
  State: NOTYETINSTALLED
  Depends On Me:
    persistence.units:jar=Test.jar,unitName=manager1


and when i look up the session bean , i get ejb not bound exception

Pls help

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:45:55 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:45:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-84) Anonymous Simple Type
 causes NullPointerException
Message-ID: <13683052.1158669955992.JavaMail.jira@cloud.prod.atl2.jboss.com>

Anonymous Simple Type causes NullPointerException
-------------------------------------------------

                 Key: JBXB-84
                 URL: http://jira.jboss.com/jira/browse/JBXB-84
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Bug
            Reporter: Heiko Braun




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:48:00 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBXB-83) XOPIncludeHandler
 should not work on InputStreams
Message-ID: <3414500.1158670080341.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-83?page=all ]

Heiko Braun deleted JBXB-83:
----------------------------


> XOPIncludeHandler should not work on InputStreams
> -------------------------------------------------
>
>                 Key: JBXB-83
>                 URL: http://jira.jboss.com/jira/browse/JBXB-83
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: Heiko Braun
>
> The XOPInclude works on ObjectInputStreams. This disaalows paasing thorugh XB to JBossWS. AFAIK that code piece is obsolete and can be removed.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:48:00 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:48:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBXB-84) Anonymous Simple Type
 causes NullPointerException
Message-ID: <22912456.1158670080457.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-84?page=all ]

Heiko Braun deleted JBXB-84:
----------------------------


> Anonymous Simple Type causes NullPointerException
> -------------------------------------------------
>
>                 Key: JBXB-84
>                 URL: http://jira.jboss.com/jira/browse/JBXB-84
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>            Reporter: Heiko Braun
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:49:56 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 08:49:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-82) Release CR7 that
 aligns with AS 4.0.5.GA
In-Reply-To: <5411313.1158669716890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26680982.1158670196371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-82?page=all ]

Heiko Braun updated JBXB-82:
----------------------------

    Assignee: Alexey Loubyansky
    Priority: Critical  (was: Major)

> Release CR7 that aligns with AS 4.0.5.GA
> ----------------------------------------
>
>                 Key: JBXB-82
>                 URL: http://jira.jboss.com/jira/browse/JBXB-82
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>            Priority: Critical
>
> JBossWS has a dependency on it.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 08:55:56 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 08:55:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-140) Move samples out of
	docs
Message-ID: <19507011.1158670556332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move samples out of docs
------------------------

                 Key: JBESB-140
                 URL: http://jira.jboss.com/jira/browse/JBESB-140
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation, ESB Core, Examples
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
            Priority: Minor
             Fix For: 4.0


The trailblazer needs to be more prominent in the distribution and source. Let's move it out of the docs directory and into it's own, at the same level as docs.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:24:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-39) Add more QA and
	unit tests
Message-ID: <32499154.1158672298917.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-39?page=comments#action_12343578 ] 
            
Mark Little commented on JBESB-39:
----------------------------------

Tom, about 6 weeks prior to release can you go through the code and let the team know which pieces need more coverage?

> Add more QA and unit tests
> --------------------------
>
>                 Key: JBESB-39
>                 URL: http://jira.jboss.com/jira/browse/JBESB-39
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>            Reporter: Mark Little
>         Assigned To: Tom Fennelly
>            Priority: Critical
>             Fix For: 4.0
>
>          Time Spent: 1 week, 4 minutes
>  Remaining Estimate: 0 minutes
>
> The Rosetta codebase does not come with a lot of tests. We need a lot more before the beta release and certainly for the 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

        


From jira-events at jboss.com  Tue Sep 19 09:24:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:24:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-126) Remove references to
 LDAP and Processors from diagrams in programmers guide.
In-Reply-To: <12554070.1155119832550.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15095174.1158672299119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-126?page=all ]

Mark Little updated JBESB-126:
------------------------------

    Priority: Minor  (was: Major)

> Remove references to LDAP and Processors from diagrams in programmers guide.
> ----------------------------------------------------------------------------
>
>                 Key: JBESB-126
>                 URL: http://jira.jboss.com/jira/browse/JBESB-126
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:26:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:26:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-65) Tidy-up ESB common
	structure
Message-ID: <20957952.1158672418261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-65?page=all ]

Mark Little reassigned JBESB-65:
--------------------------------

    Assignee: Mark Little  (was: Johan Kumps)

> Tidy-up ESB common structure
> ----------------------------
>
>                 Key: JBESB-65
>                 URL: http://jira.jboss.com/jira/browse/JBESB-65
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>
> - common\src\org\jboss\soa\esb\common\EsbSysProps.java
> 1) Needs name changing, that could imply we need a generic System/Configuration/Property management component/
> 2) Need to standardise naming and casing:
> jbossEsb.mail.smtp.host to (example) jboss.soa.esb.endpoint.email.host this provides a structured / 'packaged' grouped property. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:26:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:26:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-65) Tidy-up ESB common
	structure
Message-ID: <26120633.1158672418462.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-65?page=all ]

Mark Little closed JBESB-65.
----------------------------

    Resolution: Done

This will happen as a result of enforcing a style convention and the refactoring towards the new architecture.

> Tidy-up ESB common structure
> ----------------------------
>
>                 Key: JBESB-65
>                 URL: http://jira.jboss.com/jira/browse/JBESB-65
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> - common\src\org\jboss\soa\esb\common\EsbSysProps.java
> 1) Needs name changing, that could imply we need a generic System/Configuration/Property management component/
> 2) Need to standardise naming and casing:
> jbossEsb.mail.smtp.host to (example) jboss.soa.esb.endpoint.email.host this provides a structured / 'packaged' grouped property. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:26:58 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 09:26:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-133) Hosting trailblazer
	on docs site
In-Reply-To: <18695146.1155655940638.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29169442.1158672418783.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-133?page=all ]

Mark Little updated JBESB-133:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Hosting trailblazer on docs site
> --------------------------------
>
>                 Key: JBESB-133
>                 URL: http://jira.jboss.com/jira/browse/JBESB-133
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>            Priority: Minor
>             Fix For: 4.1
>
>
> We should look at hosting the TB here along with some good writeup on it, diagrams explaining each step of the way, etc...
>  
> http://www.jboss.com/docs/demos

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 09:55:01 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Tue, 19 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-130) wrong director in
 testJBossESB.bat
In-Reply-To: <9970749.1155632177858.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22029711.1158674101129.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-130?page=all ]

Daniel Brum resolved JBESB-130.
-------------------------------

    Resolution: Done

removed reference to 'product' folder from BAT file.

> wrong director in testJBossESB.bat
> ----------------------------------
>
>                 Key: JBESB-130
>                 URL: http://jira.jboss.com/jira/browse/JBESB-130
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>
> Issue 2
> testJBossESB.bat contains references to the "product" folder which is no longer part of beta1 src download.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:00:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14905226.1158674401557.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=comments#action_12343584 ] 
            
Clebert Suconic commented on JBMESSAGING-541:
---------------------------------------------

After JBREM-596 is fixed this task will be just to update Remoting to a stable version with the fix

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Tue Sep 19 10:00:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Tue, 19 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3640) Clustering of the
 quartz-ra.rar failes
In-Reply-To: <21839615.1157995183907.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15500372.1158674401735.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3640?page=all ]

Weston Price resolved JBAS-3640.
--------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
       Resolution: Done

Simple fix for volatility property discrepancy. Also added durable and recoverable flags to the QuartzActivationSpec.

> Clustering of the quartz-ra.rar failes
> --------------------------------------
>
>                 Key: JBAS-3640
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3640
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Clustered JBoss where the Quartz-ra.rar is set up for clustering by using any JDBC DataStore
>            Reporter: Kerry Barnes
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.GA
>
>
> When using a JDBC Data Store for the Quarts-ra.rar, the rar fails by indicating that you cannot have a non-volatile trigger associated with a volatile job.
> The JobStoreCMT file checks to make sure that if the JobDetail is marked as "volatile" the corresponding Trigger is also marked as "volatile." But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to "true" during construction, but the CronTrigger doesn't supply that option at construction and the default setting is to have the volatility set to "false," which is never changed. A mismatch and a problem
> The easiest solution is to modify the JobDetail construction volatility parameter to false so that both instances match. In my tests this generates the desired effect.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:30:03 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Tue, 19 Sep 2006 10:30:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-139) Add in ftp support
In-Reply-To: <25718589.1158654181382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28293174.1158676203489.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-139?page=all ]

Esteban Schifman resolved JBESB-139.
------------------------------------

    Resolution: Done

Rosetta implemented Ftp downloads with a message listener.  This has now changed to a remote directory polling using FTP.  
This implementation has significantly more overhead but is more resilient to network problems.
Ftp uploads use a traditional local DirectoryPoller and the FtpUpload class as 'action class'

> Add in ftp support
> ------------------
>
>                 Key: JBESB-139
>                 URL: http://jira.jboss.com/jira/browse/JBESB-139
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>          Time Spent: 3 days
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:46:58 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 10:46:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-641) process end
	subprocess cascading
Message-ID: <5668819.1158677218525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-641?page=all ]

Tom Baeyens updated JBPM-641:
-----------------------------

    Fix Version/s: jBPM 3.2 alpha 2
                       (was: jBPM 3.2 alpha 1)

> process end subprocess cascading
> --------------------------------
>
>                 Key: JBPM-641
>                 URL: http://jira.jboss.com/jira/browse/JBPM-641
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> it seems that there is no cascading to subprocesses if a process instance is ended.
> afaik, this should be implemented in the token.end method.  there should be a check on wether there is a subprocessinstance available.  if that is the case, the subprocess instance should be ended.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:50:59 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 10:50:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-746) replace
 NullPointerExceptions with JbpmExceptions
In-Reply-To: <24411573.1157618008353.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10048461.1158677459497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-746?page=all ]

Tom Baeyens closed JBPM-746.
----------------------------

    Resolution: Done

> replace NullPointerExceptions with JbpmExceptions
> -------------------------------------------------
>
>                 Key: JBPM-746
>                 URL: http://jira.jboss.com/jira/browse/JBPM-746
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1
>
>
> replace the NPE's thrown by jbpm with JbpmExceptions.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 10:50:59 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 19 Sep 2006 10:50:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-732) remove process start
 link for processes without start task
In-Reply-To: <7236390.1155567977653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5640276.1158677459619.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-732?page=all ]

Tom Baeyens updated JBPM-732:
-----------------------------

    Fix Version/s: jBPM 3.2 alpha 2
                       (was: jBPM 3.2 alpha 1)

> remove process start link for processes without start task
> ----------------------------------------------------------
>
>                 Key: JBPM-732
>                 URL: http://jira.jboss.com/jira/browse/JBPM-732
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> a check should be added to the start new process execution list on the home page that verifies if the process has a forms.xml.  if not, the start process link should not be 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

        


From jira-events at jboss.com  Tue Sep 19 10:55:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 19 Sep 2006 10:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-141) Add a glosssary of
	terms
Message-ID: <19331127.1158677701044.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a glosssary of terms
------------------------

                 Key: JBESB-141
                 URL: http://jira.jboss.com/jira/browse/JBESB-141
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Tue Sep 19 11:22:57 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Tue, 19 Sep 2006 11:22:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-132) Trailblazer build
 assumes it will be created from the svn repository.
In-Reply-To: <11633603.1155632898031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30428240.1158679377833.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-132?page=all ]

Daniel Brum resolved JBESB-132.
-------------------------------

    Resolution: Done

updated build.xml and template property file to not reference the 'product' folder anymore.

> Trailblazer build assumes it will be created from the svn repository.
> ---------------------------------------------------------------------
>
>                 Key: JBESB-132
>                 URL: http://jira.jboss.com/jira/browse/JBESB-132
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>             Fix For: 4.0 Beta 1 Maintenance Pack 1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 12:10:56 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Tue, 19 Sep 2006 12:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBXB-85) Add support for base64
 simple types to be XOP optimized
Message-ID: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for base64 simple types to be XOP optimized
-------------------------------------------------------

                 Key: JBXB-85
                 URL: http://jira.jboss.com/jira/browse/JBXB-85
             Project: JBoss XML Binding (JBossXB)
          Issue Type: Feature Request
            Reporter: Heiko Braun


Currently this only works with complex types. In order to be interoperable with MSFT we need to support this.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-6) Make sure the GPD is
 published in the
 local repository when building the jpdl suite and that the copy from the
 local repository is not taken.
Message-ID: <13450250.1158685738065.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make sure the GPD is published in the local repository when building the jpdl suite and that the copy from the local repository is not taken.
---------------------------------------------------------------------------------------------------------------------------------------------

                 Key: GPD-6
                 URL: http://jira.jboss.com/jira/browse/GPD-6
             Project: JBoss jBPM GPD
          Issue Type: Task
          Components: jpdl
    Affects Versions: 3.0.12
            Reporter: Koen Aers
         Assigned To: Koen Aers
            Priority: Critical
             Fix For: 3.0.11




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (GPD-6) Make sure the GPD is
 published in the
 local repository when building the jpdl suite and that the copy from the
 local repository is not taken.
In-Reply-To: <13450250.1158685738065.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10812256.1158685738145.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-6?page=all ]

Koen Aers updated GPD-6:
------------------------

        Fix Version/s: 3.0.12
                           (was: 3.0.11)
    Affects Version/s: 3.0.11
                           (was: 3.0.12)

> Make sure the GPD is published in the local repository when building the jpdl suite and that the copy from the local repository is not taken.
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GPD-6
>                 URL: http://jira.jboss.com/jira/browse/GPD-6
>             Project: JBoss jBPM GPD
>          Issue Type: Task
>          Components: jpdl
>    Affects Versions: 3.0.11
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Critical
>             Fix For: 3.0.12
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (GPD-7) Generation of simple
 task forms for tasks.
Message-ID: <744949.1158685738218.JavaMail.jira@cloud.prod.atl2.jboss.com>

Generation of simple task forms for tasks.
------------------------------------------

                 Key: GPD-7
                 URL: http://jira.jboss.com/jira/browse/GPD-7
             Project: JBoss jBPM GPD
          Issue Type: Feature Request
          Components: jpdl
    Affects Versions: 3.0.11
            Reporter: Koen Aers
         Assigned To: Koen Aers
            Priority: Critical
             Fix For: 3.0.12




-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:08:58 2006
From: jira-events at jboss.com (Koen Aers (JIRA))
Date: Tue, 19 Sep 2006 13:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (GPD-7) Generation of simple task
 forms for tasks.
In-Reply-To: <744949.1158685738218.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16038802.1158685738295.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/GPD-7?page=all ]

Koen Aers closed GPD-7.
-----------------------

    Resolution: Done

This is implemented

> Generation of simple task forms for tasks.
> ------------------------------------------
>
>                 Key: GPD-7
>                 URL: http://jira.jboss.com/jira/browse/GPD-7
>             Project: JBoss jBPM GPD
>          Issue Type: Feature Request
>          Components: jpdl
>    Affects Versions: 3.0.11
>            Reporter: Koen Aers
>         Assigned To: Koen Aers
>            Priority: Critical
>             Fix For: 3.0.12
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:27:00 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Tue, 19 Sep 2006 13:27:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-655) Refactor
	@Service beans
In-Reply-To: <30703765.1153251191416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9041615.1158686820681.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-655?page=comments#action_12343600 ] 
            
Carlo de Wolf commented on EJBTHREE-655:
----------------------------------------

The @Management interface must be registrered into the controller for @Depends to work. Else the dependency will never be satisfied from the controller's point of view.

That means that the controller will call create/start/stop/destroy on the @Management interface, resulting in calls to the container which has already done that.

At that point the create/start/stop/destroy methods in both @Management and the bean become a double edged sword because either it's the management interface getting c/s/s/d-ed or it's the container getting c/s/s/d-ed.

> Refactor @Service beans
> -----------------------
>
>                 Key: EJBTHREE-655
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-655
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Refactor @Service beans to fix a number of problems:
> * magic methods for lifecycle methods:
>   - create/start/stop/destroy
> * lifecycle methods are not required to be in @Management (MBean) interface.
> * @Management interface is not registered with the ServiceController (Controller in MC land).  It *IS* registered as a regular MBean though.
> * If lifecycle methods exist on @Management interface, they must be intercepted on the container so that the appropriate Controler start/stop is done on the container.  This would mean that you have to specify a <bind> in the Service aspect domain in ejb3-interceptors-aop.xml

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:28:56 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Tue, 19 Sep 2006 13:28:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-138) trailblazer demo has
 problems in some locales
In-Reply-To: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12475903.1158686936888.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-138?page=all ]

Kurt Stam updated JBESB-138:
----------------------------

    Description: 
There a re parsing problems when converting a string (1000,00) to Double.

There was another formatting issue in the CustomerAdapter.java. 

  was:There a re parsing problems when converting a string (1000,00) to Double.


> trailblazer demo has problems in some locales
> ---------------------------------------------
>
>                 Key: JBESB-138
>                 URL: http://jira.jboss.com/jira/browse/JBESB-138
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Kurt Stam
>         Attachments: patch.txt
>
>
> There a re parsing problems when converting a string (1000,00) to Double.
> There was another formatting issue in the CustomerAdapter.java. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:30:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 13:30:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
In-Reply-To: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27735277.1158687057359.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-89?page=all ]

Clebert Suconic closed JBSER-89.
--------------------------------

    Resolution: Done

> StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSER-89
>                 URL: http://jira.jboss.com/jira/browse/JBSER-89
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.1 GA, 1.0.2 GA
>            Reporter: Manik Surtani
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA
>
>
> See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:30:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 13:30:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSER-89) StringUtil UTF size
 calculation
 fails for Strings of between 32K and 64K in size (but accurate again for
 larger Strings)
In-Reply-To: <27549325.1158079774814.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6619368.1158687057531.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSER-89?page=comments#action_12343601 ] 
            
Clebert Suconic commented on JBSER-89:
--------------------------------------

I have imported these tests into jboss-serialization code.


The fix is in place also.

> StringUtil UTF size calculation fails for Strings of between 32K and 64K in size (but accurate again for larger Strings)
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBSER-89
>                 URL: http://jira.jboss.com/jira/browse/JBSER-89
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.1 GA, 1.0.2 GA
>            Reporter: Manik Surtani
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA
>
>
> See org.jboss.cache.marshall.TreeCacheMarshaller200Test - testLargerString(), test64KString() and testLargeStringMultiByte() in JBoss Cache CVS HEAD

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 13:37:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 13:37:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSER-86) The distribution jar
 manifest contains obsolete version information
In-Reply-To: <7606513.1155111192460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5054190.1158687477338.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-86?page=all ]

Clebert Suconic closed JBSER-86.
--------------------------------

    Resolution: Done

> The distribution jar manifest contains obsolete version information
> -------------------------------------------------------------------
>
>                 Key: JBSER-86
>                 URL: http://jira.jboss.com/jira/browse/JBSER-86
>             Project: JBoss Serialization
>          Issue Type: Bug
>    Affects Versions: 1.0.2 GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.3 GA
>
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: JBoss Inc.
> version: 1.0.0.RC1
> Main-Class: org.jboss.serial.Version

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:05:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 14:05:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-547) Upgrade
 JBossSerialization to 1.0.3.GA
Message-ID: <24696517.1158689157470.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade JBossSerialization to 1.0.3.GA
--------------------------------------

                 Key: JBMESSAGING-547
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.0.1.CR5


I will do it as soon as the release is out.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:10:00 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Tue, 19 Sep 2006 14:10:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBESB-138) trailblazer demo
 has problems in some locales
In-Reply-To: <16296577.1158329557276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3465156.1158689400788.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-138?page=all ]

Kurt Stam resolved JBESB-138.
-----------------------------

    Resolution: Done

> trailblazer demo has problems in some locales
> ---------------------------------------------
>
>                 Key: JBESB-138
>                 URL: http://jira.jboss.com/jira/browse/JBESB-138
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Kurt Stam
>         Attachments: patch.txt
>
>
> There a re parsing problems when converting a string (1000,00) to Double.
> There was another formatting issue in the CustomerAdapter.java. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:11:55 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Tue, 19 Sep 2006 14:11:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBIDE-365) Changing hostname
 in server
 config (JBoss 'Server Editor'), breaks twiddle monitoring for server
 startup
In-Reply-To: <24852255.1157723849263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8381562.1158689515085.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-365?page=all ]

Robert Stryker resolved JBIDE-365.
----------------------------------

    Fix Version/s: 2.0.0.Beta3
       Resolution: Done

Changing host in the editor correctly modifies the launch configuration attributes now. 

> Changing hostname in server config (JBoss 'Server Editor'), breaks twiddle monitoring for server startup
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-365
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-365
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>         Environment: Windows Server 2003
> eclipse-M20060823-1200 (eclipse 3.2)
> JBoss-4.0.4.GA
> jdk1.5.0_06
>            Reporter: Johans Marvin Taboada Villca
>         Assigned To: Robert Stryker
>             Fix For: 2.0.0.Beta3
>
>
> Changing hostname in server config view breaks twiddle monitoring for server startup
> Posible cause, maybe JBossIDE (?JBossAS Adapter?) access to twiddle script doesn't use yet
> $WORKSPACE\.metadata\.plugins\org.eclipse.wst.server.core\servers.xml
> to set -s option on the twiddle script.
> Also, changing hostname doesn't change Launch configuration, where argument '--host=localhost' is set by default.
> file: $WORKSPACE\.metadata\.plugins\org.eclipse.debug.core\.launches\JBoss-4.0.4.GA.launch

-- 
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

       



From jira-events at jboss.com  Tue Sep 19 14:13:56 2006
From: jira-events at jboss.com (Robert Stryker (JIRA))
Date: Tue, 19 Sep 2006 14:13:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBIDE-362) NPE from
 org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
In-Reply-To: <24905392.1157642431741.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18920376.1158689636810.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBIDE-362?page=all ]

Robert Stryker resolved JBIDE-362.
----------------------------------

    Fix Version/s: 2.0.0.Beta2
       Resolution: Done

check for blank files added. 

> NPE from org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports
> -----------------------------------------------------------------------------------
>
>                 Key: JBIDE-362
>                 URL: http://jira.jboss.com/jira/browse/JBIDE-362
>             Project: JBoss IDE
>          Issue Type: Bug
>          Components: JBossAS Adapter
>    Affects Versions: 2.0.0.Beta1
>            Reporter: Darryl Miles
>         Assigned To: Robert Stryker
>             Fix For: 2.0.0.Beta2
>
>
> Just thought I'd report this.
> java.lang.NullPointerException
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.supports(ArchiveModuleFactory.java:64)
> at org.jboss.ide.eclipse.as.core.module.factory.ArchiveModuleFactory.acceptAddition(ArchiveModuleFactory.java:33)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory$1.visit(JBossModuleFactory.java:88)
> at org.eclipse.core.internal.resources.Resource$2.visit(Resource.java:105)
> at org.eclipse.core.internal.resources.Resource$1.visitElement(Resource.java:57)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:81)
> at org.eclipse.core.internal.watson.ElementTreeIterator.doIteration(ElementTreeIterator.java:85)
> at org.eclipse.core.internal.watson.ElementTreeIterator.iterate(ElementTreeIterator.java:126)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:67)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:103)
> at org.eclipse.core.internal.resources.Resource.accept(Resource.java:87)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.cacheModules(JBossModuleFactory.java:86)
> at org.jboss.ide.eclipse.as.core.module.factory.JBossModuleFactory.getModules(JBossModuleFactory.java:66)
> at org.eclipse.wst.server.core.internal.ModuleFactory.getModules(ModuleFactory.java:133)
> at org.eclipse.wst.server.core.ServerUtil.getModules(ServerUtil.java:285)
> at org.eclipse.wst.server.core.ServerUtil.getModule(ServerUtil.java:52)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.gatherModuleReference(ComponentDeployable.java:126)
> at org.eclipse.jst.j2ee.internal.deployables.J2EEFlexProjDeployable.gatherModuleReference(J2EEFlexProjDeployable.java:466)
> at org.eclipse.wst.web.internal.deployables.ComponentDeployable.getModules(ComponentDeployable.java:113)
> at org.eclipse.jst.server.tomcat.core.internal.TomcatServer.getChildModules(TomcatServer.java:212)
> at org.eclipse.wst.server.core.internal.Server.getChildModules(Server.java:2174)
> at org.eclipse.wst.server.core.internal.Server.visitModule(Server.java:2334)
> at org.eclipse.wst.server.core.internal.Server.visit(Server.java:2315)
> at org.eclipse.wst.server.core.internal.Server.shouldRestart(Server.java:805)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableLabelProvider.getColumnText(ServerTableLabelProvider.java:183)
> at org.eclipse.jface.viewers.TreeViewer.doUpdateItem(TreeViewer.java:309)
> at org.eclipse.jface.viewers.AbstractTreeViewer$UpdateItemSafeRunnable.run(AbstractTreeViewer.java:95)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.AbstractTreeViewer.doUpdateItem(AbstractTreeViewer.java:849)
> at org.eclipse.jface.viewers.StructuredViewer$UpdateItemSafeRunnable.run(StructuredViewer.java:465)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
> at org.eclipse.core.runtime.Platform.run(Platform.java:843)
> at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44)
> at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149)
> at org.eclipse.jface.viewers.StructuredViewer.updateItem(StructuredViewer.java:1955)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createTreeItem(AbstractTreeViewer.java:753)
> at org.eclipse.jface.viewers.AbstractTreeViewer$1.run(AbstractTreeViewer.java:731)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.jface.viewers.AbstractTreeViewer.createChildren(AbstractTreeViewer.java:705)
> at org.eclipse.jface.viewers.TreeViewer.createChildren(TreeViewer.java:892)
> at org.eclipse.jface.viewers.AbstractTreeViewer$5.run(AbstractTreeViewer.java:1288)
> at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1323)
> at org.eclipse.jface.viewers.AbstractTreeViewer.inputChanged(AbstractTreeViewer.java:1277)
> at org.eclipse.jface.viewers.ContentViewer.setInput(ContentViewer.java:250)
> at org.eclipse.jface.viewers.StructuredViewer.setInput(StructuredViewer.java:1542)
> at org.eclipse.wst.server.ui.internal.view.servers.ServerTableViewer.<init>(ServerTableViewer.java:240)
> at org.eclipse.wst.server.ui.internal.view.servers.ServersView.createPartControl(ServersView.java:89)
> at org.eclipse.ui.internal.ViewReference.createPartHelper(ViewReference.java:332)
> at org.eclipse.ui.internal.ViewReference.createPart(ViewReference.java:197)
> at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:566)
> at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:290)
> at org.eclipse.ui.internal.ViewPane.setVisible(ViewPane.java:525)
> at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:140)
> at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268)
> at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65)
> at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:394)
> at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1144)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:620)
> at org.eclipse.ui.internal.PartStack.createControl(PartStack.java:532)
> at org.eclipse.ui.internal.PartSashContainer.createControl(PartSashContainer.java:562)
> at org.eclipse.ui.internal.PerspectiveHelper.activate(PerspectiveHelper.java:244)
> at org.eclipse.ui.internal.Perspective.onActivate(Perspective.java:815)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3284)
> at org.eclipse.ui.internal.WorkbenchPage.busySetPerspective(WorkbenchPage.java:957)
> at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:941)
> at org.eclipse.ui.internal.WorkbenchPage$12.run(WorkbenchPage.java:3408)
> at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67)
> at org.eclipse.ui.internal.WorkbenchPage.setPerspective(WorkbenchPage.java:3406)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem.select(PerspectiveBarContributionItem.java:123)
> at org.eclipse.ui.internal.PerspectiveBarContributionItem$1.widgetSelected(PerspectiveBarContributionItem.java:92)
> at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
> at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
> at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1085)
> at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3166)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2842)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
> at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
> at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
> at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
> at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
> at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
> 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:336)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:26:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11101043.1158690361227.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343605 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Deadlock:

2006-09-18 22:06:46,109 6281  TRACE [org.jboss.jms.server.container.ServerLogInterceptor] @main invoking ConsumerAdvised->ConsumerEndpoint[-2147483626].close()
2006-09-18 22:06:46,109 6281  TRACE [org.jboss.jms.server.endpoint.ServerConsumerEndpoint] @Thread-3 ConsumerEndpoint[-2147483626] receives Reference[1537]:RELIABLE for delivery

The main thread tries to close the ConsumerEndpoint, grabs ConsumerEndpoint's main lock and gets stuck trying to get Channel->Router->receivers' lock, in process of removing the ConsumerEndpoint from the channel.
Thread-3 has  Channel->Router->receivers' lock and gets stuck trying to grab ConsumerEndpoint's main lock.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:40:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28036489.1158691201333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov updated JBMESSAGING-546:
----------------------------------------

    Comment: was deleted

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:40:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33277498.1158691201450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343607 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Deadlock:

2006-09-18 22:06:46,109 6281 TRACE [org.jboss.jms.server.container.ServerLogInterceptor] @main invoking ConsumerAdvised->ConsumerEndpoint[-2147483626].close()
2006-09-18 22:06:46,109 6281 TRACE [org.jboss.jms.server.endpoint.ServerConsumerEndpoint] @Thread-3 ConsumerEndpoint[-2147483626] receives Reference[1537]:RELIABLE for delivery



> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:40:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21710069.1158691201578.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343608 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Increased tracing resolution.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-502) Create a MSSQL
 persistence manager config
In-Reply-To: <29492968.1155039912398.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6151663.1158692217961.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-502?page=all ]

Ovidiu Feodorov closed JBMESSAGING-502.
---------------------------------------


> Create a MSSQL persistence manager config
> -----------------------------------------
>
>                 Key: JBMESSAGING-502
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-502
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Luc Texier
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-90) Generate a
 correct manifest file
Message-ID: <13021367.1158692218158.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-90?page=all ]

Ovidiu Feodorov closed JBMESSAGING-90.
--------------------------------------


> Generate a correct manifest file
> --------------------------------
>
>                 Key: JBMESSAGING-90
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-90
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Build System
>            Reporter: Ovidiu Feodorov
>         Assigned To: Alex Fu
>             Fix For: 1.0.0 beta
>
>
> Generate a manifest that contains correct versioning information when creating distribution archives (jars/sars)

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-278)
	JMSXDeliveryCount support
Message-ID: <4322425.1158692218692.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-278?page=all ]

Ovidiu Feodorov closed JBMESSAGING-278.
---------------------------------------


> JMSXDeliveryCount support
> -------------------------
>
>                 Key: JBMESSAGING-278
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-278
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: JMS Facade
>            Reporter: Ovidiu Feodorov
>         Assigned To: Alex Fu
>             Fix For: 1.0.0
>
>
> While running TCK, tests fail because the current TCK version doesn't handle well  JMSXDeliveryCount. The temporary solution is to disable Messaging support for it (JBossMessage.gettPropertyNames() just doesn't return it anymore).
> This happens because TCK thinks all properties returned by Message.getPropertyNames() as String properties, tries to getStringProperty("JMSXDeliveryCount"), gets null because the correct way to retrieve JMSXDeliveryCount is getIntProperty() and dies with NullPointerException.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 14:56:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 14:56:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-311) Add destination
 deployment params test
Message-ID: <27877407.1158692219118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-311?page=all ]

Ovidiu Feodorov closed JBMESSAGING-311.
---------------------------------------


> Add destination deployment params test
> --------------------------------------
>
>                 Key: JBMESSAGING-311
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-311
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Alex Fu
>             Fix For: 1.0.1.CR1
>
>
> A bug was fixed just before 1.0 release where destination params were being validated on each setXXX call, causing destinations to de deployed with the wrong params.
> This has been fixed, but test needs to be added to prevent this happening again.
> Imagine I have queue with fullSize = 100, pageSize = 50, downCacheSize = 50
> I then want to set the queue to have fullSize = 1000, pageSize = 500, downCacheSize = 500
> If I attempt to set the queue's downCacheSize to 500 then it will fail to set it, since the downCacheSize would temporarily be more than fullSize. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 15:00:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 15:00:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25312481.1158692454744.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343610 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

the code should contain sufficient trace statements to identify and fix the deadlock, when it occurs.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 15:00:54 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 15:00:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15412864.1158692454896.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov updated JBMESSAGING-546:
----------------------------------------

    Priority: Major  (was: Critical)

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 16:07:58 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Tue, 19 Sep 2006 16:07:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3554) Upgrade JBoss AS
 to use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16354846.1158696478637.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3554?page=comments#action_12343616 ] 
            
Stan Silvert commented on JBAS-3554:
------------------------------------

MyFaces 1.1.4 is finally out.  As long as my integration tests pass, I should be able to have it into 4.0.5 within 24 hours.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 16:09:59 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Tue, 19 Sep 2006 16:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28849079.1158696599659.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Stan Silvert updated JBAS-3554:
-------------------------------

    Fix Version/s:     (was: JBossAS-5.0.0.Beta)

Removed 5.0.0 Beta as "Fix Version".  5.0.0 uses glassfish CDDL JSF instead of MyFaces.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:28:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 19 Sep 2006 17:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2614) Add a stress test of
 region activation/inactivation under load
Message-ID: <5661937.1158701281214.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2614?page=all ]

Brian Stansberry updated JBAS-2614:
-----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Add a stress test of region activation/inactivation under load
> --------------------------------------------------------------
>
>                 Key: JBAS-2614
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2614
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> There are already tests of this in the JBossCache testsuite, but a test that involves the JBossCacheManager layer as well would be good.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:36:01 2006
From: jira-events at jboss.com (Keith Gregory (JIRA))
Date: Tue, 19 Sep 2006 17:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3670)
 org.jboss.axis.ConfigurationException: No engine configuration file
Message-ID: <7732126.1158701761366.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.axis.ConfigurationException: No engine configuration file
-------------------------------------------------------------------

                 Key: JBAS-3670
                 URL: http://jira.jboss.com/jira/browse/JBAS-3670
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Keith Gregory
         Assigned To: Thomas Diesler
            Priority: Minor


The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.

Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.

The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.

The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:36:01 2006
From: jira-events at jboss.com (Keith Gregory (JIRA))
Date: Tue, 19 Sep 2006 17:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3671)
 org.jboss.axis.ConfigurationException: No engine configuration file
Message-ID: <13187415.1158701761524.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.axis.ConfigurationException: No engine configuration file
-------------------------------------------------------------------

                 Key: JBAS-3671
                 URL: http://jira.jboss.com/jira/browse/JBAS-3671
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Keith Gregory
         Assigned To: Thomas Diesler
            Priority: Minor


The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.

Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.

The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.

The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
new Service(new FileProvider("META-INF/axis-client-config.xml"))

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:46:01 2006
From: jira-events at jboss.com (Keith Gregory (JIRA))
Date: Tue, 19 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3671)
 org.jboss.axis.ConfigurationException: No engine configuration file
In-Reply-To: <13187415.1158701761524.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18041774.1158702361342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3671?page=comments#action_12343626 ] 
            
Keith Gregory commented on JBAS-3671:
-------------------------------------

Looking at the 4.0.4 GA source tree, this has not been fixed.

> org.jboss.axis.ConfigurationException: No engine configuration file
> -------------------------------------------------------------------
>
>                 Key: JBAS-3671
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3671
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Keith Gregory
>         Assigned To: Thomas Diesler
>            Priority: Minor
>
> The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client.
> Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it.
> The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB.
> The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file:
> new Service(new FileProvider("META-INF/axis-client-config.xml"))

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 17:52:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 19 Sep 2006 17:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-326) Create the
 concept of a
 "priority queue" to speed execution of certain remote method invocations
Message-ID: <14449729.1158702721371.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-326?page=comments#action_12343627 ] 
            
Brian Stansberry commented on JBCACHE-326:
------------------------------------------

I'm not 100% sure, but this likely won't improve much for state transfer once FLUSH is done.  I guess the benefit would be if block call were stuck in the jg up queue because a preceding repl msg is held up by a lock conflict.  Probably we should wait and see what comes out of implementing block() .

> Create the concept of a "priority queue" to speed execution of certain remote method invocations
> ------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-326
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-326
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0
>
>
> Change the handling of requests in JBossCache (another  interceptor on top of ReplicationInterceptor): 
> - Create 2 queues (of MethodCall objects), one thread for each queue 
> - The regular MethodCalls like put(), remove() etc go into the  default queue (A), where they are processed according to order (FIFO) 
> - The special calls like block(), _getState(), commit() or acks  for PREPARE/COMMIT calls go into the other (priority) queue (B),  these calls *CAN* be received out of sequence 
> - This way, an _getState() would always be processed and  would be able to (1) stop the processing of queue A and (2) force- release any locks held 
>   by on the tree.
> _ This way commit() calls can promptly release locks, without having to wait behind other prepare 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

        


From jira-events at jboss.com  Tue Sep 19 17:54:01 2006
From: jira-events at jboss.com (chi lin (JIRA))
Date: Tue, 19 Sep 2006 17:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBADMCON-149) Support JBoss
	Messaging
Message-ID: <24165467.1158702841307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support JBoss Messaging
-----------------------

                 Key: JBADMCON-149
                 URL: http://jira.jboss.com/jira/browse/JBADMCON-149
             Project: JBoss Admin Console
          Issue Type: Feature Request
          Components: General Console
    Affects Versions: 1.1 alpha
            Reporter: chi lin
         Assigned To: chi lin
             Fix For: 1.1 alpha


Since JBoss Messaging will be the default JMS provider for JBoss AS 5.x, the Admin Console should support JBoss Messaging instead of (or in addition to) JBossMQ. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:02:01 2006
From: jira-events at jboss.com (chi lin (JIRA))
Date: Tue, 19 Sep 2006 18:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBADMCON-149) Support JBoss
	Messaging
In-Reply-To: <24165467.1158702841307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31666934.1158703321256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-149?page=all ]

chi lin updated JBADMCON-149:
-----------------------------

    Attachment: SupportJBossMessaging.pdf

The attached file contains a mini-design and work break-down to support JBoss Messaging. Your comments are welcome!

> Support JBoss Messaging
> -----------------------
>
>                 Key: JBADMCON-149
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-149
>             Project: JBoss Admin Console
>          Issue Type: Feature Request
>          Components: General Console
>    Affects Versions: 1.1 alpha
>            Reporter: chi lin
>         Assigned To: chi lin
>             Fix For: 1.1 alpha
>
>         Attachments: SupportJBossMessaging.pdf
>
>
> Since JBoss Messaging will be the default JMS provider for JBoss AS 5.x, the Admin Console should support JBoss Messaging instead of (or in addition to) JBossMQ. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:10:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 18:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBSER-88) Create
	DataContainer.clone method
In-Reply-To: <10710529.1156790206090.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29786390.1158703801260.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-88?page=all ]

Clebert Suconic reopened JBSER-88:
----------------------------------

             

> Create DataContainer.clone method
> ---------------------------------
>
>                 Key: JBSER-88
>                 URL: http://jira.jboss.com/jira/browse/JBSER-88
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.1.0 Beta, 1.0.3 GA
>
>
> DataContainer was not meant to be multi-thread. However if you want to use Datacontainer as an object factory it would be possible to reuse its internal data in a clone operation, and then use the result in a multi-thread environment.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:10:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 18:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSER-88) DataContainer.clone
	method
In-Reply-To: <10710529.1156790206090.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30246168.1158703801369.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-88?page=all ]

Clebert Suconic updated JBSER-88:
---------------------------------

    Summary: DataContainer.clone method  (was: Create DataContainer.clone method)

> DataContainer.clone method
> --------------------------
>
>                 Key: JBSER-88
>                 URL: http://jira.jboss.com/jira/browse/JBSER-88
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.1.0 Beta, 1.0.3 GA
>
>
> DataContainer was not meant to be multi-thread. However if you want to use Datacontainer as an object factory it would be possible to reuse its internal data in a clone operation, and then use the result in a multi-thread environment.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:10:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Tue, 19 Sep 2006 18:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSER-88) DataContainer.clone
	method
In-Reply-To: <10710529.1156790206090.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32584975.1158703801495.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSER-88?page=all ]

Clebert Suconic closed JBSER-88.
--------------------------------

    Resolution: Done

> DataContainer.clone method
> --------------------------
>
>                 Key: JBSER-88
>                 URL: http://jira.jboss.com/jira/browse/JBSER-88
>             Project: JBoss Serialization
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.3 GA, 1.1.0 Beta
>
>
> DataContainer was not meant to be multi-thread. However if you want to use Datacontainer as an object factory it would be possible to reuse its internal data in a clone operation, and then use the result in a multi-thread environment.

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 18:30:01 2006
From: jira-events at jboss.com (Peter Johnson (JIRA))
Date: Tue, 19 Sep 2006 18:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBADMCON-149) Support JBoss
	Messaging
In-Reply-To: <24165467.1158702841307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31397318.1158705001237.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBADMCON-149?page=all ]

Peter Johnson updated JBADMCON-149:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972762

> Support JBoss Messaging
> -----------------------
>
>                 Key: JBADMCON-149
>                 URL: http://jira.jboss.com/jira/browse/JBADMCON-149
>             Project: JBoss Admin Console
>          Issue Type: Feature Request
>          Components: General Console
>    Affects Versions: 1.1 alpha
>            Reporter: chi lin
>         Assigned To: chi lin
>             Fix For: 1.1 alpha
>
>         Attachments: SupportJBossMessaging.pdf
>
>
> Since JBoss Messaging will be the default JMS provider for JBoss AS 5.x, the Admin Console should support JBoss Messaging instead of (or in addition to) JBossMQ. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 19:00:01 2006
From: jira-events at jboss.com (Stan Silvert (JIRA))
Date: Tue, 19 Sep 2006 19:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11622762.1158706801266.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Stan Silvert resolved JBAS-3554.
--------------------------------

    Resolution: Done

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Tue Sep 19 19:42:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 19:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28904112.1158709321250.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343635 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

Can't get it to repeat, with the new tracing code. Repeat it in a loop.

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 19 20:55:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 19 Sep 2006 20:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-542) Closing
 connection inside MessageListener's onMessage() causes deadlock
In-Reply-To: <24917780.1158015569074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29175.1158713701092.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-542?page=all ]

Ovidiu Feodorov closed JBMESSAGING-542.
---------------------------------------

    Resolution: Done

Fixed by modifying the SessionAspect to send to server accumulated AUTO and DUPS_OK acknowledgments on closing, and then skip postDeliver() to avoid passing through a "closed" ClosedInterceptor.

> Closing connection inside MessageListener's onMessage() causes deadlock
> -----------------------------------------------------------------------
>
>                 Key: JBMESSAGING-542
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-542
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 00:41:53 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 00:41:53 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1043091.1158727313489.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343639 ] 
            
Tom  Elrod commented on JBREM-596:
----------------------------------

Have updated code so that client invoker is responsible for handling lease management for all Clients using that client invoker.  The org.jboss.test.remoting.lease.socket.multiple package test case is passing now.

The main benefit for this (other than fixing original bug) is that instead of having a thread per Client doing lease ping, will only be one thread per client invoker (regardless of number of Clients using that client invoker).  

This change does raise some issues with regards to some of the more obscure behaviors, which have been listed in forum post - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972805#3972805

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 00:43:54 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 00:43:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8916942.1158727434467.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343640 ] 
            
Tom  Elrod commented on JBREM-596:
----------------------------------

Clebert, can you verify this fix for messaging?

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 02:29:56 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Wed, 20 Sep 2006 02:29:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3672) EJB3.0 session bean
 look up and data source configuration
Message-ID: <21983529.1158733796302.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3.0 session bean look up and data source configuration
---------------------------------------------------------

                 Key: JBAS-3672
                 URL: http://jira.jboss.com/jira/browse/JBAS-3672
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.CR2
         Environment: Windows 2000 Professional , JBoss 4.0.4CR2, SQL Server 2005
            Reporter: madan srinivas
         Assigned To: Bill Burke


I have deployed datasource using mssqlds.xml in jboss/server/default/deploy

sqljdbc.jar has been placed in jboss/server/default/lib directory

driver class is com.microsoft.sqlserver.jdbc.SQLServerDriver but if i use it i get Wrong driver class error 

hence i changed it to com.microsoft.jdbc.sqlserver.SQLServerDriver but irt fails to register the river 

Error : 
Caused by: org.jboss.resource.JBossResourceException: Failed to register driver
for: com.microsoft.jdbc.sqlserver.SQLServerDriver; - nested throwable: (java.lan
g.ClassNotFoundException: No ClassLoaders found for: com.microsoft.jdbc.sqlserve
r.SQLServerDriver)

Server output on console for EJB deployment : 

But when i do jndi look up i get received timed out error , pls help

11:47:06,356 INFO  [NamingHelper] JNDI InitialContext properties:{java.naming.fa
ctory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.p
kgs=org.jboss.naming:org.jnp.interfaces}
11:47:06,403 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Test.
jar,name=FileDetailsClientBean,service=EJB3 with dependencies:
11:47:06,403 INFO  [JmxKernelAbstraction]       persistence.units:jar=Test.jar,u
nitName=manager1
11:47:06,653 INFO  [EJBContainer] STARTED EJB: com.hqs.ppsadvantage.ejb.FileDeta
ilsClientBean ejbName: FileDetailsClientBean
11:47:06,731 INFO  [EJB3Deployer] Deployed: file:/D:/jboss-4.0.4.CR2/server/defa
ult/deploy/Test.jar

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 03:27:57 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 03:27:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3672) EJB3.0 session bean
 look up and data source configuration
In-Reply-To: <21983529.1158733796302.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18875163.1158737277110.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3672?page=all ]

Dimitris Andreadis closed JBAS-3672.
------------------------------------

    Resolution: Rejected

Please use the forums for this type of questions.

> EJB3.0 session bean look up and data source configuration
> ---------------------------------------------------------
>
>                 Key: JBAS-3672
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3672
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>         Environment: Windows 2000 Professional , JBoss 4.0.4CR2, SQL Server 2005
>            Reporter: madan srinivas
>         Assigned To: Bill Burke
>
> I have deployed datasource using mssqlds.xml in jboss/server/default/deploy
> sqljdbc.jar has been placed in jboss/server/default/lib directory
> driver class is com.microsoft.sqlserver.jdbc.SQLServerDriver but if i use it i get Wrong driver class error 
> hence i changed it to com.microsoft.jdbc.sqlserver.SQLServerDriver but irt fails to register the river 
> Error : 
> Caused by: org.jboss.resource.JBossResourceException: Failed to register driver
> for: com.microsoft.jdbc.sqlserver.SQLServerDriver; - nested throwable: (java.lan
> g.ClassNotFoundException: No ClassLoaders found for: com.microsoft.jdbc.sqlserve
> r.SQLServerDriver)
> Server output on console for EJB deployment : 
> But when i do jndi look up i get received timed out error , pls help
> 11:47:06,356 INFO  [NamingHelper] JNDI InitialContext properties:{java.naming.fa
> ctory.initial=org.jnp.interfaces.NamingContextFactory, java.naming.factory.url.p
> kgs=org.jboss.naming:org.jnp.interfaces}
> 11:47:06,403 INFO  [JmxKernelAbstraction] installing MBean: jboss.j2ee:jar=Test.
> jar,name=FileDetailsClientBean,service=EJB3 with dependencies:
> 11:47:06,403 INFO  [JmxKernelAbstraction]       persistence.units:jar=Test.jar,u
> nitName=manager1
> 11:47:06,653 INFO  [EJBContainer] STARTED EJB: com.hqs.ppsadvantage.ejb.FileDeta
> ilsClientBean ejbName: FileDetailsClientBean
> 11:47:06,731 INFO  [EJB3Deployer] Deployed: file:/D:/jboss-4.0.4.CR2/server/defa
> ult/deploy/Test.jar

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 04:17:54 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 04:17:54 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21562578.1158740274463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Dimitris Andreadis reopened JBAS-3554:
--------------------------------------

             
The 1.1.4 libraries in the repository should not contain the version numbers in the filenames, so I corrected that.

In fact, I see the same mistake is made in the myfaces-1.1.3 version, but I didn't correct this there, since I'm not sure where else this is already used.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From c12 at fullmailmarket.com  Wed Sep 20 04:36:27 2006
From: c12 at fullmailmarket.com (Hostex.cl)
Date: Wed, 20 Sep 2006 04:36:27 -0400
Subject: [jboss-jira] WebHosting Profesional.
Message-ID: <200609200836.k8K8aTHM008232@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060920/cdfc88b9/attachment-0001.html 

From jira-events at jboss.com  Wed Sep 20 05:38:01 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Wed, 20 Sep 2006 05:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3674) service
 MetricsLookup dont show invocations
Message-ID: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>

service MetricsLookup dont show invocations
-------------------------------------------

                 Key: JBAS-3674
                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-3.2.7 Final
         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
jdk1.5.0_06
Intel Xeon CPU
            Reporter: abo abo


on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.

metrics-service.xml:
=============================================================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->

<server>

  <classpath codebase="lib"
             archives="jboss.jar"/>

  <!-- ==================================================================== -->
  <!-- Metrics Service                                                    -->
  <!-- ==================================================================== -->

  <mbean code="org.jboss.ejb.plugins.MetricsLookup"
          name="jboss:service=MetricsLookup">
          <attribute name="SanityInterval">120000</attribute>
          <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
          <attribute name="EjbPattern">*</attribute>
          <attribute name="MethodPattern">*</attribute>
          <attribute name="ShowParams">true</attribute>
  </mbean>

</server>
=============================================================


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:35:01 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:35:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-142) Add support for
 processing
 messages received by Listeners through a pipeline of action processors.
Message-ID: <22412365.1158748501271.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support for processing messages received by Listeners through a pipeline of action processors.
--------------------------------------------------------------------------------------------------

                 Key: JBESB-142
                 URL: http://jira.jboss.com/jira/browse/JBESB-142
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0
            Reporter: Tom Fennelly
         Assigned To: Mark Little
             Fix For: 4.0


Rosetta supported a 1:1 listener to action handler message processing model.  We need to be able to push the messages into a pipeline of action processors.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:38:00 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-142) Add support for
 processing
 messages received by Listeners through a pipeline of action processors.
In-Reply-To: <22412365.1158748501271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29476344.1158748680684.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-142?page=all ]

Tom Fennelly closed JBESB-142.
------------------------------

    Resolution: Done

See http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

> Add support for processing messages received by Listeners through a pipeline of action processors.
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBESB-142
>                 URL: http://jira.jboss.com/jira/browse/JBESB-142
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0
>            Reporter: Tom Fennelly
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>   Original Estimate: 1 week, 3 days
>  Remaining Estimate: 1 week, 3 days
>
> Rosetta supported a 1:1 listener to action handler message processing model.  We need to be able to push the messages into a pipeline of action processors.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:40:00 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-143) Add Action
 Pipelining info to the Programmers Guide
Message-ID: <31051559.1158748800070.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add Action Pipelining info to the Programmers Guide
---------------------------------------------------

                 Key: JBESB-143
                 URL: http://jira.jboss.com/jira/browse/JBESB-143
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0
            Reporter: Tom Fennelly
         Assigned To: Mark Little
             Fix For: 4.0


Move Action Processing Pipeline info from the Wiki to the programmers guide.

Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:40:00 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-143) Add Action
 Pipelining info to the Programmers Guide
In-Reply-To: <31051559.1158748800070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6626236.1158748800223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-143?page=all ]

Tom Fennelly reassigned JBESB-143:
----------------------------------

    Assignee: Tom Fennelly  (was: Mark Little)

> Add Action Pipelining info to the Programmers Guide
> ---------------------------------------------------
>
>                 Key: JBESB-143
>                 URL: http://jira.jboss.com/jira/browse/JBESB-143
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0
>            Reporter: Tom Fennelly
>         Assigned To: Tom Fennelly
>             Fix For: 4.0
>
>
> Move Action Processing Pipeline info from the Wiki to the programmers guide.
> Wiki: http://wiki.jboss.org/wiki/Wiki.jsp?page=ActionProcessingPipelines

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 06:53:01 2006
From: jira-events at jboss.com (Tom Fennelly (JIRA))
Date: Wed, 20 Sep 2006 06:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-142) Add support for
 processing
 messages received by Listeners through a pipeline of action processors.
In-Reply-To: <22412365.1158748501271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15499004.1158749581330.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-142?page=all ]

Tom Fennelly reassigned JBESB-142:
----------------------------------

    Assignee: Tom Fennelly  (was: Mark Little)

> Add support for processing messages received by Listeners through a pipeline of action processors.
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBESB-142
>                 URL: http://jira.jboss.com/jira/browse/JBESB-142
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0
>            Reporter: Tom Fennelly
>         Assigned To: Tom Fennelly
>             Fix For: 4.0
>
>   Original Estimate: 1 week, 3 days
>          Time Spent: 1 week, 3 days
>  Remaining Estimate: 0 minutes
>
> Rosetta supported a 1:1 listener to action handler message processing model.  We need to be able to push the messages into a pipeline of action processors.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 07:21:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Wed, 20 Sep 2006 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3674) service MetricsLookup
 dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12607200.1158751261187.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3674?page=all ]

Adrian Brock closed JBAS-3674.
------------------------------

    Resolution: Out of Date

Use jsr77

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 07:56:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 07:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-5) Leverage existing tools
Message-ID: <12277072.1158753360142.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-5?page=all ]

Mark Little closed JBESB-5.
---------------------------

    Resolution: Out of Date

> Leverage existing tools
> -----------------------
>
>                 Key: JBESB-5
>                 URL: http://jira.jboss.com/jira/browse/JBESB-5
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBI Core
>            Reporter: Joseph Marques
>         Assigned To: Mark Little
>
> Why doesn't JBoss start from and extend one of the current open source ESB solutions such as Mule or ServiceMix (the latter of which has a core JBI 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

        


From jira-events at jboss.com  Wed Sep 20 07:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 07:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-144) Add unit tests for
 new EPR and messaging classes.
Message-ID: <3775013.1158753481061.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add unit tests for new EPR and messaging classes.
-------------------------------------------------

                 Key: JBESB-144
                 URL: http://jira.jboss.com/jira/browse/JBESB-144
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep 20 08:00:58 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Wed, 20 Sep 2006 08:00:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-710) Cleanup E-EJB3
 package/code/logging
Message-ID: <20336427.1158753658361.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cleanup E-EJB3 package/code/logging
-----------------------------------

                 Key: EJBTHREE-710
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-710
             Project: EJB 3.0
          Issue Type: Bug
    Affects Versions: EJB 3.0 RC9 - FD
            Reporter: Christian Bauer
            Priority: Blocker


This is E-EJB3 RC9. The following issues are not minor, they would make me feel uneasy if I was a user:

1. The bundled embedded-jboss-beans.xml uses xmlns="urn:jboss:bean-deployer" and everybody gets a nice WARN on startup that xmlns="urn:jboss:bean-deployer:2.0" should be used. Change that in the distributed configuration file.

2. [java] 13:40:10,676  WARN Ejb3Configuration:104 - Persistence provider caller does not implements the EJB3 spec correctly. PersistenceUnitInfo.getNewTempClassLoader() is null. It's OK to warn users that something is not right, but if something is not right in our distribution there should be a note in the README or something that tells me as a user that this is OK for the moment. Like a link to a JIRA issue.

3. [java] 13:44:59,381  WARN JBossTimerServiceFactory:112 - TIMER SERVICE IS NOT INSTALLED -- Uh, yes, because I don't want it. Find a way for users to disable this warning. I don't see any way to disable the timer service in embedded-jboss-beans.xml and I don't want the .rar and .jar in my libs.

4. In RC9 there is code that prints debugging stuff on STDOUT:

     [java] lookup 
     [java]   UserTransaction: org.jboss.ejb3.embedded.UserTransactionImpl
     [java]   MessageHandlerBean: org.jnp.interfaces.NamingContext  

This is triggered by EJB3StandaloneBootstrap.scanClasspath("helloworld-ejb3/build"), please remove from code...



-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:18:01 2006
From: jira-events at jboss.com (Mladen Turk (JIRA))
Date: Wed, 20 Sep 2006 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3495) Windows service
	for JBossAS
In-Reply-To: <33245776.1155052753127.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9415354.1158754681242.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3495?page=comments#action_12343649 ] 
            
Mladen Turk commented on JBAS-3495:
-----------------------------------

Right, if those are the main entry classes for run/shutdown.
The new shutdown would have additional Send ConsoleCtrlEvent to the running service,
just like if the user would hit CRTL+C in the 'normal window'.

BTW, do we have a daily SVN snapshots for the trunk?


> Windows service for JBossAS
> ---------------------------
>
>                 Key: JBAS-3495
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3495
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: Win32
>            Reporter: Luc Texier
>             Fix For: JBossAS-5.0.0.Beta
>
>
> Windows users have a hard time deploying JBossAS as a Windows service.  Most of them try to use JavaService from ObjectWeb which is too generic to support properly an application server instance. For exemple, generating thread dumps is impossible. Also the experience has shown that this tool is fairly broken causing hang-ups. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:18:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Wed, 20 Sep 2006 08:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27770935.1158754681414.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-98?page=comments#action_12343650 ] 
            
Jonathan Halliday commented on JBTM-98:
---------------------------------------

Per above forum reference, issue was reported as problem with Xid length when using Oracle 10g OCI JDBC driver, with suggested fix:

"The driver does not like the global and branch qualifier IDs if they are not padded to 64 bytes. I have modified the methods XidImple.getGlobalTransactionId() and XidImple.getBranchQualifier() to return a padded array of 64 bytes."

Attempted to reproduce the issue using Oracle 10g release 2 on linux for both client and server. Unable to reproduce issue, XA transaction worked ok.  Oracle may have fixed issue in their driver by 10g, so I also attempted to reproduce the issue using Oracle 9i release 2 client/server on linux. Still worked.

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:21:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Wed, 20 Sep 2006 08:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17969937.1158754861299.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-98?page=all ]

Jonathan Halliday resolved JBTM-98.
-----------------------------------

    Resolution: Cannot Reproduce Bug


Unable to reproduce bug. no code changes made.

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 08:21:01 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Wed, 20 Sep 2006 08:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-85) Add support for base64
 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8427555.1158754861441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-85?page=all ]

Heiko Braun updated JBXB-85:
----------------------------

        Summary: Add support for base64 simple type bean properties to be XOP optimized  (was: Add support for base64 simple types to be XOP optimized)
    Description: 
Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:

<xs:element name="EchoBinaryAsString">
	<xs:complexType>
	<xs:sequence>
<xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
</xs:sequence>
</xs:complexType>
</xs:element>

The type xs:base64Binary needs be optimized by jbossxb.

  was:Currently this only works with complex types. In order to be interoperable with MSFT we need to support this.


> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Wed, 20 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1832) Improving JBoss
 WebConsole's snapshots
Message-ID: <7268833.1158758461838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1832?page=all ]

Darran Lofthouse updated JBAS-1832:
-----------------------------------

    Component/s: Web Console
                     (was: Management services)

> Improving JBoss WebConsole's snapshots
> --------------------------------------
>
>                 Key: JBAS-1832
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1832
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.0 Final
>         Environment: Not relevant
>            Reporter: Mathieu Bourrier
>            Priority: Minor
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The snapshots in the Webconsole cannot be started automatically on startup, as the Recording field isn't an attribute.
> 2 classes need to be modified, and the changes are quite small.
> Given topic describes changes to be made in order to manage it.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:02 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Wed, 20 Sep 2006 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-1832) Improving JBoss
 WebConsole's snapshots
Message-ID: <23925209.1158758462010.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1832?page=all ]

Darran Lofthouse reassigned JBAS-1832:
--------------------------------------

    Assignee: Darran Lofthouse

> Improving JBoss WebConsole's snapshots
> --------------------------------------
>
>                 Key: JBAS-1832
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1832
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Console
>    Affects Versions: JBossAS-4.0.0 Final
>         Environment: Not relevant
>            Reporter: Mathieu Bourrier
>         Assigned To: Darran Lofthouse
>            Priority: Minor
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> The snapshots in the Webconsole cannot be started automatically on startup, as the Recording field isn't an attribute.
> 2 classes need to be modified, and the changes are quite small.
> Given topic describes changes to be made in order to manage it.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:02 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Wed, 20 Sep 2006 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-148) Include
 Tomcat's
 SavedRequest object into the replication process in a Jboss-Tomcat
 clustered environment to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2076455.1158758462383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=comments#action_12343654 ] 
            
Alberto Rodriguez commented on JBCLUSTER-148:
---------------------------------------------

It's been pointed in Tomcat's developers list that section 7.7.2 (Distributed Environments) of JSR-154 (Servlet specfication) is said:

"Within an application marked as distributable, all requests that are part of a session must be handled by one Java Virtual Machine at a time"

This invalidates our approach unless that paragraph is changed in subsecuent revisions of the specfication ( this probably won't happen in the near future because of it's distributed VM shynchronization implications).



> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:21:02 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Wed, 20 Sep 2006 09:21:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCLUSTER-148) Include Tomcat's
 SavedRequest
 object into the replication process in a Jboss-Tomcat clustered environment
 to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6366477.1158758462641.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=all ]

Alberto Rodriguez closed JBCLUSTER-148.
---------------------------------------

    Resolution: Deferred

> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:23:01 2006
From: jira-events at jboss.com (Alberto Rodriguez (JIRA))
Date: Wed, 20 Sep 2006 09:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCLUSTER-148) Include
 Tomcat's
 SavedRequest object into the replication process in a Jboss-Tomcat
 clustered environment to allow proper Single Sign On capabilities
In-Reply-To: <24215598.1157961403832.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30442773.1158758581252.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCLUSTER-148?page=comments#action_12343655 ] 
            
Alberto Rodriguez commented on JBCLUSTER-148:
---------------------------------------------

A copy of the interchanged messages can be read here:

http://marc.theaimsgroup.com/?l=tomcat-dev&m=115858715404605&w=2

> Include Tomcat's SavedRequest object into the replication process in a Jboss-Tomcat clustered environment to allow proper Single Sign On capabilities
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCLUSTER-148
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-148
>             Project: JBoss Clustering
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: Q2Y6
>         Environment: independent
>            Reporter: Alberto Rodriguez
>         Assigned To: Brian Stansberry
>            Priority: Optional
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> In a JBoss clustered environment where session is replicated and single sign on is enabled, one cannot log in an protected clustered web application because of the lack of Serialization support of Tomcat's SavedRequest object.
> Tomcat stores the information needed to restore the pre-authentication request in a note in the session in a SavedRequest object, this object is not included in the replication process because it doesn't implement Serializable.
> The objective would be to make SavedRequest object Serializable in Tomcat and include this object and/or other notes in the serialization process executed when the session info is replicated.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:25:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Wed, 20 Sep 2006 09:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3675) Add LockOwnerName to
 ThreadDump output from ServerInfo
Message-ID: <25533160.1158758701199.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add LockOwnerName to ThreadDump output from ServerInfo
------------------------------------------------------

                 Key: JBAS-3675
                 URL: http://jira.jboss.com/jira/browse/JBAS-3675
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMX
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Darran Lofthouse
         Assigned To: Darran Lofthouse
             Fix For: JBossAS-4.0.6.CR1


The current thread dump shows what object a thread is waiting on but it does not show which thread currently owns the lock.

Add getLockOwnerName for each thread output.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:33:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30918891.1158759181364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Tom  Elrod updated JBREM-596:
-----------------------------

    Priority: Critical  (was: Major)

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:36:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-381) IIOP transport impl
	for remoting
Message-ID: <14843697.1158759361590.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-381?page=all ]

Tom  Elrod updated JBREM-381:
-----------------------------

    Priority: Minor  (was: Critical)

> IIOP transport impl for remoting
> --------------------------------
>
>                 Key: JBREM-381
>                 URL: http://jira.jboss.com/jira/browse/JBREM-381
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.1 final
>            Reporter: Tom  Elrod
>         Assigned To: Ron Sigal
>            Priority: Minor
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:36:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-562) publish performance
	benchmarks
In-Reply-To: <17974196.1154504171466.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15027063.1158759361717.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-562?page=all ]

Tom  Elrod closed JBREM-562.
----------------------------

    Resolution: Done

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972805#3972805

> publish performance benchmarks
> ------------------------------
>
>                 Key: JBREM-562
>                 URL: http://jira.jboss.com/jira/browse/JBREM-562
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: general
>    Affects Versions: 2.0.0.CR1 (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:36:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 09:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-47) Dynamic classloading
Message-ID: <31948240.1158759361231.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-47?page=all ]

Tom  Elrod updated JBREM-47:
----------------------------

    Priority: Major  (was: Critical)

> Dynamic classloading
> --------------------
>
>                 Key: JBREM-47
>                 URL: http://jira.jboss.com/jira/browse/JBREM-47
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>          Components: general
>    Affects Versions: 1.0.1 beta
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> Need ability for dynamic classloading to satisfy two needs. The first, is when an ejb lookup is done, and if do not have the class on the client, can download the client classes for remoting. This is much more efficient than having to serialize all these classes (as there may be many and may not even know what they are until runtime). Also, would like to add the ability for client or server to pass implementation for interfaces across the wire and if the other side does not have those classes, can load them. Once particular case when this might be needed is if using JMX sub-system, client could create custom QueryExp? implementation and pass to the server, and the server could load that class and perform the query. Will require security around this.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 09:51:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 20 Sep 2006 09:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-308) DataModel
 instance changes
 even though the backing list did not when using PAGE scope
In-Reply-To: <29938082.1152829515513.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32960037.1158760261318.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-308?page=comments#action_12343661 ] 
            
Gavin King commented on JBSEAM-308:
-----------------------------------

Is it related to this forum thread: [url]http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972892#3972892[/url]

> DataModel instance changes even though the backing list did not when using PAGE scope
> -------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-308
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-308
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>            Reporter: Chris Rudd
>
> The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected.
> When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. 
> The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. 
> I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection.
> I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ):
>  private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper)
>    {
>       
>       Context context = getDataModelContext(scope);
>       Object existingDataModel = context.get(name);
>       boolean dirty = existingDataModel == null || 
>             !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality
>       
>       if ( dirty )
>       {
>          if ( list != null )
>          {
>             context.set( name, wrapper.wrap(list) );
>          }
>          else
>          {
>             context.remove( name );
>          }
>       }
>       // If page scope, outject the existingDataModel even if there was no change
>       else if( scope==ScopeType.PAGE )
>       {
>          context.set( name, existingDataModel );
>       }
>       
>    }

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:19:59 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 10:19:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-145) Automate the
 trailblazer as part of QA
Message-ID: <6932816.1158761999738.JavaMail.jira@cloud.prod.atl2.jboss.com>

Automate the trailblazer as part of QA
--------------------------------------

                 Key: JBESB-145
                 URL: http://jira.jboss.com/jira/browse/JBESB-145
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Examples, Testing
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
             Fix For: 4.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

        


From jira-events at jboss.com  Wed Sep 20 10:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 10:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-9) Remote the dom4j
 dependency from org.jboss.util.state.xml.StateMachineParser
Message-ID: <11341338.1158763621358.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remote the dom4j dependency from org.jboss.util.state.xml.StateMachineParser
----------------------------------------------------------------------------

                 Key: JBCOMMON-9
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-9
             Project: JBoss Common
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: core
    Affects Versions: 1.0.0.CR1
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: 2.0.0.Beta, 1.0.0.GA


StateMachineParser is the only class in the common package that has a dependency on dom4j.

Re-write it so the dom4j dependency is removed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 10:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-9) Remove the dom4j
 dependency from org.jboss.util.state.xml.StateMachineParser
In-Reply-To: <11341338.1158763621358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13550077.1158763621502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-9?page=all ]

Dimitris Andreadis updated JBCOMMON-9:
--------------------------------------

    Summary: Remove the dom4j dependency from org.jboss.util.state.xml.StateMachineParser  (was: Remote the dom4j dependency from org.jboss.util.state.xml.StateMachineParser)

> Remove the dom4j dependency from org.jboss.util.state.xml.StateMachineParser
> ----------------------------------------------------------------------------
>
>                 Key: JBCOMMON-9
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-9
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.0.0.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: 2.0.0.Beta, 1.0.0.GA
>
>
> StateMachineParser is the only class in the common package that has a dependency on dom4j.
> Re-write it so the dom4j dependency is removed.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:47:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 20 Sep 2006 10:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3676) Upgrade jboss-common
	to 1.0.0.GA
Message-ID: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss-common to 1.0.0.GA
--------------------------------

                 Key: JBAS-3676
                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Other
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Wed Sep 20 10:57:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 10:57:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-84) The Xid
 implementation should
 implement the hashCode and equals methods from Object
Message-ID: <17429363.1158764279575.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-84?page=comments#action_12343665 ] 
            
Kevin Conner commented on JBTM-84:
----------------------------------

This issue has been fixed in revision 6317.


> The Xid implementation should implement the hashCode and equals methods from Object
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-84
>                 URL: http://jira.jboss.com/jira/browse/JBTM-84
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> XidImpl does not implement the equals and hashCode methods.  This prevents Xid being used in hash maps/sets.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 10:57:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 10:57:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-84) The Xid
 implementation should
 implement the hashCode and equals methods from Object
Message-ID: <31114480.1158764279713.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-84?page=all ]

Kevin Conner resolved JBTM-84.
------------------------------

    Fix Version/s: 4.2.2
       Resolution: Done

> The Xid implementation should implement the hashCode and equals methods from Object
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-84
>                 URL: http://jira.jboss.com/jira/browse/JBTM-84
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> XidImpl does not implement the equals and hashCode methods.  This prevents Xid being used in hash maps/sets.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:11:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-286) Weaken dependencies
 on unreleased MC 2.0
Message-ID: <13804037.1158765061202.JavaMail.jira@cloud.prod.atl2.jboss.com>

Weaken dependencies on unreleased MC 2.0
----------------------------------------

                 Key: JBAOP-286
                 URL: http://jira.jboss.com/jira/browse/JBAOP-286
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.0.0.alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:11:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-287) Tighten integration
 with MC 2.0 once it is released
Message-ID: <5859857.1158765061379.JavaMail.jira@cloud.prod.atl2.jboss.com>

Tighten integration with MC 2.0 once it is released
---------------------------------------------------

                 Key: JBAOP-287
                 URL: http://jira.jboss.com/jira/browse/JBAOP-287
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 2.0.0.alpha2




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:17:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:17:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-124) atsintegration must
 have its own logging
Message-ID: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>

atsintegration must have its own logging
----------------------------------------

                 Key: JBTM-124
                 URL: http://jira.jboss.com/jira/browse/JBTM-124
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.2.1
         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:24:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-125) The transaction
 manager implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
Message-ID: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>

The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
--------------------------------------------------------------------------------------------------------------------------

                 Key: JBTM-125
                 URL: http://jira.jboss.com/jira/browse/JBTM-125
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-126) JTS XATerminator
 references arjunacore classes
Message-ID: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>

JTS XATerminator references arjunacore classes
----------------------------------------------

                 Key: JBTM-126
                 URL: http://jira.jboss.com/jira/browse/JBTM-126
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-126) JTS XATerminator
 references arjunacore classes
In-Reply-To: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17529656.1158766381466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-126?page=comments#action_12343666 ] 
            
Kevin Conner commented on JBTM-126:
-----------------------------------

Updates to the jts XATerminator were made in version 6318.

> JTS XATerminator references arjunacore classes
> ----------------------------------------------
>
>                 Key: JBTM-126
>                 URL: http://jira.jboss.com/jira/browse/JBTM-126
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-126) JTS XATerminator
 references arjunacore classes
In-Reply-To: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26535044.1158766381583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-126?page=all ]

Kevin Conner resolved JBTM-126.
-------------------------------

    Resolution: Done

> JTS XATerminator references arjunacore classes
> ----------------------------------------------
>
>                 Key: JBTM-126
>                 URL: http://jira.jboss.com/jira/browse/JBTM-126
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-124) atsintegration must
 have its own logging
In-Reply-To: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6688625.1158766381785.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-124?page=comments#action_12343667 ] 
            
Kevin Conner commented on JBTM-124:
-----------------------------------

Fixed in revision 6318.

> atsintegration must have its own logging
> ----------------------------------------
>
>                 Key: JBTM-124
>                 URL: http://jira.jboss.com/jira/browse/JBTM-124
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-124) atsintegration must
 have its own logging
In-Reply-To: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4961949.1158766381921.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-124?page=all ]

Kevin Conner resolved JBTM-124.
-------------------------------

    Resolution: Done

> atsintegration must have its own logging
> ----------------------------------------
>
>                 Key: JBTM-124
>                 URL: http://jira.jboss.com/jira/browse/JBTM-124
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:33:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 20 Sep 2006 11:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-121) Check recovery
In-Reply-To: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11516905.1158766382309.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-121?page=all ]

Mark Little updated JBTM-121:
-----------------------------

    Fix Version/s: 4.4
                       (was: 4.2.2)

> Check recovery
> --------------
>
>                 Key: JBTM-121
>                 URL: http://jira.jboss.com/jira/browse/JBTM-121
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.4
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:35:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:35:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-125) The transaction
 manager implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
In-Reply-To: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11545845.1158766559204.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-125?page=comments#action_12343668 ] 
            
Kevin Conner commented on JBTM-125:
-----------------------------------

Fixed in revision 6319.

> The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-125
>                 URL: http://jira.jboss.com/jira/browse/JBTM-125
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:35:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:35:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-125) The transaction
 manager implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
In-Reply-To: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7457325.1158766559376.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-125?page=all ]

Kevin Conner resolved JBTM-125.
-------------------------------

    Resolution: Done

> The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-125
>                 URL: http://jira.jboss.com/jira/browse/JBTM-125
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:38:00 2006
From: jira-events at jboss.com (Daniel Hannum (JIRA))
Date: Wed, 20 Sep 2006 11:38:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3258) JDBC artificats
 should throw SQLException when already closed
Message-ID: <7934716.1158766680316.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3258?page=comments#action_12343669 ] 
            
Daniel Hannum commented on JBAS-3258:
-------------------------------------

This temporary fix is not working for me. It won't compile because the two @Bind annotations are not allowed (duplicate annotation, it says). I've tried to adjust the pointcut to make it work with a single bind and it still throws the exceptions and still won't hit a breakpoint in the aspect.

How long until 4.0.4SP1 is out?

> JDBC artificats should throw SQLException when already closed
> -------------------------------------------------------------
>
>                 Key: JBAS-3258
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3258
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.5.CR1, JBossAS-4.0.4.SP1
>
>
> In the change to fix JBAS-2741 I mistakenly made the JDBC wrappers throw an SQL
> exception if the artifact is already closed. They should just return with an exception.
> From the Javadoc:
> "Calling the method close on a Statement  object that is already closed has no effect."
> e.g. In WrappedStatement
>    public void close() throws SQLException
>    {
>       synchronized (lock)
>       {
>          if (closed)
>             throw new SQLException("Already closed");
>          closed = true;
>       }
>       lc.unregisterStatement(this);
>       internalClose();
>    }
> this should be:
>    public void close() throws SQLException
>    {
>       synchronized (lock)
>       {
>          if (closed)
>             return;
>          closed = true;
>       }
>       lc.unregisterStatement(this);
>       internalClose();
>    }

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:39:59 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:39:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAOP-287) Tighten
 integration with MC 2.0 once it is released
In-Reply-To: <5859857.1158765061379.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30996014.1158766799759.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAOP-287?page=comments#action_12343670 ] 
            
Kabir Khan commented on JBAOP-287:
----------------------------------

Remove the org.jboss.aop.annotation.factory.duplicate package and make use the org.jboss.annotation.factory classes from container
Reintroduce the MetaDataContext into the org.jboss.aop.proxy.container classes (This has currently been "de-typed")
Change build script to include the container in the library.classpath so it is available both when compiling and when running the tests
Index: C:/cygwin/home/Kabir/sourcecontrol/jboss-head/aop/build.xml
===================================================================
--- C:/cygwin/home/Kabir/sourcecontrol/jboss-head/aop/build.xml	(revision 57004)
+++ C:/cygwin/home/Kabir/sourcecontrol/jboss-head/aop/build.xml	(working copy)
@@ -86,7 +86,7 @@
          <path refid="oswego.concurrent.classpath"/>
          <path refid="junit.junit.classpath"/>
          <path refid="jboss.profiler.jvmti.classpath"/>
-         <path refid="jboss.microcontainer.classpath"/>
+         <!--<path refid="jboss.microcontainer.classpath"/>-->
       </path>
 
       <!-- Defines jrockit.home -->
@@ -150,6 +150,7 @@
 
       <!-- The classpath required to build classes. -->
       <path id="javac.classpath">
+         <path refid="jboss.microcontainer.classpath"/>
          <pathelement path="${classpath}"/>
          <pathelement path="${local.classpath}"/>
          <path refid="thirdparty.classpath"/>
@@ -259,6 +260,8 @@
          <src path="${source.java}"/>
          <exclude name="org/jboss/aop/definition/**"/>
          <exclude name="org/jboss/aop/hook/JRockit*"/>
+<exclude name="**/ClassInfoMethodHashing.java"/>
+
          <classpath refid="javac.classpath"/>
       </javac>
    </target>
@@ -615,6 +618,7 @@
          <include name="**/*.java"/>
          <exclude name="org/jboss/test/aop/jdk15*/**/*.java"/>
          <exclude name="org/jboss/test/aop/memoryleaks/**/*.java"/>
+         <exclude name="**/methodhashing/*"/>
       </javac>
    </target>
 



> Tighten integration with MC 2.0 once it is released
> ---------------------------------------------------
>
>                 Key: JBAOP-287
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-287
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:45:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-596) Lease stops
 working if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25429330.1158767101375.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-596?page=comments#action_12343671 ] 
            
Clebert Suconic commented on JBREM-596:
---------------------------------------

After updating libraries ClientCrashTwoConnectionsTest  is passing without any failures. So, the fix is perfect for messaging.

We will need a tagged snapshot or a minor release for messaging now.

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:48:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <29393582.1158767281233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-87?page=all ]

Kevin Conner reassigned JBTM-87:
--------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:51:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <16575748.1158767461222.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-87?page=comments#action_12343672 ] 
            
Kevin Conner commented on JBTM-87:
----------------------------------

The LastResourceCommitOptimisation for JTA and JTS must be put back into the code base.  In addition we must support the org.jboss.tm.LastResource interface

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:53:59 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:53:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
Message-ID: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>

UID must befine a value for the maximum UID and enforce the ordering during comparison.
---------------------------------------------------------------------------------------

                 Key: JBTM-127
                 URL: http://jira.jboss.com/jira/browse/JBTM-127
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.

UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:56:00 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:56:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
In-Reply-To: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1537065.1158767760898.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-127?page=comments#action_12343673 ] 
            
Kevin Conner commented on JBTM-127:
-----------------------------------

Fixed in revision 6324.

> UID must befine a value for the maximum UID and enforce the ordering during comparison.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBTM-127
>                 URL: http://jira.jboss.com/jira/browse/JBTM-127
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.
> UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:56:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Wed, 20 Sep 2006 11:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
In-Reply-To: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14133865.1158767761025.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-127?page=all ]

Kevin Conner resolved JBTM-127.
-------------------------------

    Resolution: Done

> UID must befine a value for the maximum UID and enforce the ordering during comparison.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBTM-127
>                 URL: http://jira.jboss.com/jira/browse/JBTM-127
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.
> UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:58:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 20 Sep 2006 11:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-711) During
 undeployment stop is being called twice
Message-ID: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>

During undeployment stop is being called twice 
-----------------------------------------------

                 Key: EJBTHREE-711
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
             Project: EJB 3.0
          Issue Type: Bug
            Reporter: Carlo de Wolf
             Fix For: EJB 3.0 RC9 - FD


After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 11:58:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Wed, 20 Sep 2006 11:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <7262689.1158767881261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment: jboss-aop.jar
                jboss-aop-jdk50.jar

These files contain what will be in JBoss AOP 2.0.0.alpha1

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>         Attachments: jboss-aop-jdk50.jar, jboss-aop.jar
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 12:15:01 2006
From: jira-events at jboss.com (Phillip Thurmond (JIRA))
Date: Wed, 20 Sep 2006 12:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
Message-ID: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
------------------------------------------------------------------------------------------

                 Key: JBAS-3678
                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Sparc Solaris 10
jdk 1.4.2_08
            Reporter: Phillip Thurmond


org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10

Testcase: testMyService took 1.656 sec
        Caused an ERROR
null
java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:141)
        at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
1)
        at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
        at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
14)
        at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
137)
        at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
ava:58)
        at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
        at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
        at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
viceClientTestCase.java:70)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
s-bmp
        at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
        at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
        at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
java:77)
        at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
:63)
        ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 12:37:58 2006
From: jira-events at jboss.com (Phillip Thurmond (JIRA))
Date: Wed, 20 Sep 2006 12:37:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23612586.1158770278875.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3678?page=comments#action_12343676 ] 
            
Phillip Thurmond commented on JBAS-3678:
----------------------------------------

I have tried running this test with DISPLAY correctly set and also with -Djava.awt.headless=true.  Test still fails.



> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:02:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-600)
 org.jboss.test.remoting.lease.multiplex.MultiplexLeaseTestCase fails
Message-ID: <23571178.1158778921092.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.test.remoting.lease.multiplex.MultiplexLeaseTestCase fails
--------------------------------------------------------------------

                 Key: JBREM-600
                 URL: http://jira.jboss.com/jira/browse/JBREM-600
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport-multiplex
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Ron Sigal
             Fix For: 2.2.0.Beta1 (Bluto)


When run org.jboss.test.remoting.lease.multiplex.MultiplexLeaseTestCase, the test fails.  From debugging, the ServerInvoker's leaseManagement variable is not set to true when it's invoke() method is called (thus by-passing leasing).  

Also noticed when debugging that when Connector.addConnectionListener() calls:

invoker.addConnectionListener(listener);

that the invoker instance was MultiplexServerInvoker[master] (this is where the leaseManagement variable gets set to true) and when the PING invocation request is processed within ServerInvoker.invoke() method (where checks to see if leaseManagement variable is true and is not), the invoker instance is MultiplexServerInvoker[virtual:/127.0.0.1:5400->/127.0.0.1:1914].

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:04:57 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Wed, 20 Sep 2006 15:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-31) Migration to
	Portal 2.4
Message-ID: <13309733.1158779098003.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-31?page=all ]

Ryszard Kozmik resolved JBFORUMS-31.
------------------------------------

    Resolution: Done

> Migration to Portal 2.4
> -----------------------
>
>                 Key: JBFORUMS-31
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-31
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 1 day, 6 hours, 10 minutes
>
> Because of that JBForums have many dependencies on JBPortal and it is still changing there is a need to keep up to those changes.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:43:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 20 Sep 2006 15:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10390499.1158781381280.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Tom  Elrod resolved JBREM-596.
------------------------------

    Resolution: Done

Repository binary - http://repository.jboss.com/jboss/remoting/2.2.0.Alpha1/lib/
CVS tag - remoting_2_2_0_Alpha1

> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 15:50:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 15:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-596) Lease stops working
 if the First Client using the same Locator is closed
In-Reply-To: <11671081.1157754329434.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18582110.1158781801143.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-596?page=all ]

Clebert Suconic closed JBREM-596.
---------------------------------


> Lease stops working if the First Client using the same Locator is closed
> ------------------------------------------------------------------------
>
>                 Key: JBREM-596
>                 URL: http://jira.jboss.com/jira/browse/JBREM-596
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: callbacks
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> If you use always the same locator (say if you need socket pool working), and if you close the first Client opened, Lease will stop as Lease is associated with the Client and not with the Invoker (what is wrong IMO)
> Lease should be associated with AbstractInvoker, as the property for Lease will determine an unique ClientInvoker on InvokerRegistry.
> Test org.jboss.test.remoting.lease.socket.multiple has the scenario for this failure.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:06:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-505)
 RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by
 zero
In-Reply-To: <23865901.1155229153385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20167188.1158782761756.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-505?page=comments#action_12343685 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-505:
---------------------------------------------

Also, the same solution was applied to FirstReceiverPointToPointRouter, so if reverted, needs to be reverted on both classes.

> RoundRobinPointToPointRouter occasionally throws ArithmeticException: / by zero
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-505
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-505
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>
> This error message shows up in logs when all receivers are removed from the router. It is harmless and it doesn't affect functionality.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:09:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32170578.1158782941657.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov updated JBMESSAGING-546:
----------------------------------------

    Comment: was deleted

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:11:59 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 16:11:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17898048.1158783119957.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=all ]

Clebert Suconic updated JBMESSAGING-528:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89208  (was: http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3967042)

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:13:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:13:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14589605.1158783238630.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=comments#action_12343688 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-546:
---------------------------------------------

The main thread grabs ServerConsumerEndpoint's main lock in ServerConsumerEndpoint.close() and tries to remove itself from the channel's router. Cannot do that because Thread-3 holds the router's lock.
Thread-3 delivers a new reference to ServerConsumerEndpoint while holding the router's lock (unnecessarily), and tries to grab ServerConsumerEndpoint's main lock, which is unavailable.

The deadlock was fixed by reducing the time Thread-3 holds the router's lock. 

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:16:00 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 16:16:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-546)
 org.jboss.test.messaging.jms.DurableSubscriberTest times out
In-Reply-To: <5402720.1158645541602.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11707669.1158783360701.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-546?page=all ]

Ovidiu Feodorov closed JBMESSAGING-546.
---------------------------------------

    Resolution: Done

> org.jboss.test.messaging.jms.DurableSubscriberTest times out
> ------------------------------------------------------------
>
>                 Key: JBMESSAGING-546
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-546
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:24:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 16:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-540) A testsuite
 testing client and server on different IPs
In-Reply-To: <19860398.1157515483940.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <580584.1158783841071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-540?page=all ]

Clebert Suconic closed JBMESSAGING-540.
---------------------------------------

    Fix Version/s:     (was: 1.2.1)
       Resolution: Won't Fix

Having the integration test on JBoss AS is the right way to do this task.

We already have a JIRA issue for integration tasks.

> A testsuite testing client and server on different IPs
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-540
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-540
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>
> The current testsuite tests both client and server on the same network. 
> We should have a way to test client and server using different IPs, and possibility different network cards.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:34:00 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 20 Sep 2006 16:34:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-356) Session bean
	assertions
Message-ID: <26202711.1158784440217.JavaMail.jira@cloud.prod.atl2.jboss.com>

Session bean assertions
-----------------------

                 Key: JBSEAM-356
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-356
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King


For people who like more of a design-by-contract style, we could let you specify Hibernate Validator annotations on the session bean, and check them after @PostConstruct and before and after each business method.

eg.

@Stateful
public class Foo {
    @NotNull private Bar bar;
    @Min(0) int count;
}

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 16:47:00 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Wed, 20 Sep 2006 16:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-682) create test for
	JBossTS
In-Reply-To: <954187.1154728331873.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5522463.1158785220493.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-682?page=all ]

William DeCoste closed EJBTHREE-682.
------------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
       Resolution: Done

> create test for JBossTS
> -----------------------
>
>                 Key: EJBTHREE-682
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-682
>             Project: EJB 3.0
>          Issue Type: Task
>            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

        


From jira-events at jboss.com  Wed Sep 20 16:59:01 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 20 Sep 2006 16:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPORTAL-1046) documentation
 for Ldap/Portal integration
In-Reply-To: <28666807.1158567770641.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22563430.1158785941325.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPORTAL-1046?page=comments#action_12343694 ] 
            
Boleslaw Dawidowicz commented on JBPORTAL-1046:
-----------------------------------------------

Documentation should provide the chart/matrix with the level of support for
1/ authentication &roles
2/ profile integration
3/ role assignment

in

1/ DB implementation
2/ Simple LDAP implementation
3/ Complex LDAP implementation

> documentation for Ldap/Portal integration
> -----------------------------------------
>
>                 Key: JBPORTAL-1046
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1046
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Documentation
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>
> Create documentation of configuring Portal with LDAP. It needs to cover new implementation of identity modules in 2.6

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 17:31:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 17:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-548) Remote tests
 occasionaly fail with "Cannot find generator for serverid:server.0"
Message-ID: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remote tests occasionaly fail with "Cannot find generator for serverid:server.0"
--------------------------------------------------------------------------------

                 Key: JBMESSAGING-548
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Minor
             Fix For: 1.0.1.CR5


Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:13:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 20 Sep 2006 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1051) NPE if no
 session information exists when trying to update the user cookies
Message-ID: <22189599.1158790381710.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE if no session information exists when trying to update the user cookies
---------------------------------------------------------------------------

                 Key: JBPORTAL-1051
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1051
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:23:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 18:23:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1618819.1158791037937.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=comments#action_12343703 ] 
            
Clebert Suconic commented on JBMESSAGING-528:
---------------------------------------------

I'm updating documentation on head.

We will need to upload docs on jboss.org as soon as we get the release out.

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:30:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 18:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29863675.1158791401322.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=all ]

Clebert Suconic closed JBMESSAGING-528.
---------------------------------------

    Resolution: Done

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:40:57 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 18:40:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-528) Update user
 manual to
 include details on configuring remoting's serverBindAddress
In-Reply-To: <21164828.1156362709683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9762962.1158792057428.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-528?page=comments#action_12343706 ] 
            
Clebert Suconic commented on JBMESSAGING-528:
---------------------------------------------

Documentation also updated on Branch_1_0

> Update user manual to include details on configuring remoting's serverBindAddress
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-528
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-528
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:49:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <22904332.1158792541686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov updated JBMESSAGING-361:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:49:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <30666056.1158792541863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Ovidiu Feodorov updated JBMESSAGING-431:
----------------------------------------

    Assignee: Clebert Suconic  (was: Ron Sigal)

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:49:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 20 Sep 2006 18:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1051) NPE if no
 session information exists when trying to update the user cookies
In-Reply-To: <22189599.1158790381710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4061831.1158792541946.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1051?page=all ]

Chris Laprun resolved JBPORTAL-1051.
------------------------------------

    Resolution: Done

> NPE if no session information exists when trying to update the user cookies
> ---------------------------------------------------------------------------
>
>                 Key: JBPORTAL-1051
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1051
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:55:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:55:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <30630088.1158792958925.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov updated JBMESSAGING-361:
----------------------------------------

    Assignee: Ovidiu Feodorov  (was: Clebert Suconic)

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:55:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 18:55:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-361)
 WireFormatTest.testNullResponse(), testDeactivateResponse() fragments
 invalid
Message-ID: <6308726.1158792959053.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-361?page=all ]

Ovidiu Feodorov closed JBMESSAGING-361.
---------------------------------------

    Resolution: Done

> WireFormatTest.testNullResponse(), testDeactivateResponse() fragments invalid
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-361
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-361
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: JMS Facade
>    Affects Versions: 1.0.0
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> Switching to jboss-serialization 1.0.0.CR7 uncovered what apparently seems to be an invalid test section in WireFormatTest
>  public void testNullResponse() throws Exception
>       {
>          MessagingMarshallable mm = new MessagingMarshallable((byte)77, null);
>          InvocationResponse resp = new InvocationResponse(null, mm, false, null);
>          ByteArrayOutputStream bos = new ByteArrayOutputStream();
>          JBossObjectOutputStream oos = new JBossObjectOutputStream(bos);
>         
>          wf.write(resp, oos);
>          oos.flush();
>         
>          ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
>          DataInputStream dis = new DataInputStream(bis);
>         
>          // First byte should be version
>          assertEquals(77, dis.readByte());
>          ...........
>       }
> It doesn't make sense to me to write stuff to a JBossObjectOutputStream and then try to read the serialized content using a DataInputStream, and yet this is what this test section does. JBoss Serialization doesn't guarantee this in its public contract.
> Excerpt form a conversation with Clebert:
> flanker707: Does JBossSerialization guarantee that something written with on a JBossObjectOutuptStream can be read with DataInputStream?
> Clebert Suconic: no... I didn't mean to
> flanker707: is this in the public contract?
> Clebert Suconic: If you use the same thing with ObjectInputStream.. you would have the same problem
> testNullResponse(), testDeactivateResponse() sections commented out until clarified.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:57:58 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 20 Sep 2006 18:57:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11172959.1158793078445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3678?page=all ]

Ryan Campbell reassigned JBAS-3678:
-----------------------------------

    Assignee: Jason T. Greene

Jason,

Can you look at this?  We need this for a solaris certification for JBoss 4.0.4.  We believe it may be a bad test, but would like to have a second opinion.

Thanks,
Ryan

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Jason T. Greene
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 18:57:58 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 20 Sep 2006 18:57:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30090953.1158793078602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3678?page=all ]

Ryan Campbell updated JBAS-3678:
--------------------------------

    Comment: was deleted

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Jason T. Greene
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:35:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 19:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-548) Remote tests
 occasionaly fail with "Cannot find generator for serverid:server.0"
In-Reply-To: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22359041.1158795357382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-548?page=comments#action_12343711 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-548:
---------------------------------------------

The testsuite passes consistently if I comment out the JBossConnection.finalizer(), so until more research is done in that direction, it'll stay commented out.

> Remote tests occasionaly fail with "Cannot find generator for serverid:server.0"
> --------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-548
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:35:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 19:35:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-548)
 JBossConnection.finalizer()
 causes remote tests to occasionaly fail with "Cannot find generator for
 serverid:server.0"
In-Reply-To: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3495639.1158795357500.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-548?page=all ]

Ovidiu Feodorov updated JBMESSAGING-548:
----------------------------------------

          Summary: JBossConnection.finalizer() causes remote tests to occasionaly fail with "Cannot find generator for serverid:server.0"  (was: Remote tests occasionaly fail with "Cannot find generator for serverid:server.0")
    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)

> JBossConnection.finalizer() causes remote tests to occasionaly fail with "Cannot find generator for serverid:server.0"
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-548
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>
> Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:43:58 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 20 Sep 2006 19:43:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-431) Socket
 transports should use configurable port
Message-ID: <27706349.1158795838355.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-431?page=all ]

Clebert Suconic closed JBMESSAGING-431.
---------------------------------------

    Resolution: Done

> Socket transports should use configurable port
> ----------------------------------------------
>
>                 Key: JBMESSAGING-431
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-431
>             Project: JBoss Messaging
>          Issue Type: Task
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Currently, for the socket and ssl transports, callbackservers will be opened on the next available port obtained.
> Very occasionally this can fail since some other service uses the port before the callback server can.
> Instead, the user should be able to configure a port used by the callbackserver to listen.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 19:49:57 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Wed, 20 Sep 2006 19:49:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-186) Write a blog entry
 about the beta release
Message-ID: <5928402.1158796197448.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-186?page=all ]

Alejandro Guizar resolved BPEL-186.
-----------------------------------

    Resolution: Done

> Write a blog entry about the beta release
> -----------------------------------------
>
>                 Key: BPEL-186
>                 URL: http://jira.jboss.com/jira/browse/BPEL-186
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1 beta 2
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:10:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:10:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-547) Upgrade
 JBossSerialization to 1.0.3.GA
In-Reply-To: <24696517.1158689157470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19544870.1158797456914.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-547?page=all ]

Ovidiu Feodorov updated JBMESSAGING-547:
----------------------------------------

    Priority: Minor  (was: Major)

> Upgrade JBossSerialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBMESSAGING-547
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> I will do it as soon as the release is out.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:14:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:14:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-287)
 RemotingTest.testConnectionListener() invalid
Message-ID: <23539326.1158797697917.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-287?page=all ]

Ovidiu Feodorov updated JBMESSAGING-287:
----------------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.0.1.CR5)

> RemotingTest.testConnectionListener() invalid
> ---------------------------------------------
>
>                 Key: JBMESSAGING-287
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-287
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Beta1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I commented out that test because I wanted a clean test run for the release and also because I think the test is invalid. 
> After the client connects I assume there is a separate thread that renews the lease on server, so even if the main thread sleeps for 5 secs, the client renews its lease and the ConnectionListener doesn't get called. Please verify my assumption and either fix the test or remove it. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:14:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:14:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-541) If the first
 opened connections is closed, Remoting Lease doesn't work any more
In-Reply-To: <1335806.1157686843788.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16538182.1158797698104.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-541?page=all ]

Ovidiu Feodorov closed JBMESSAGING-541.
---------------------------------------

    Resolution: Done

fixed with Remoting 2.2.0.Alpha1

> If the first opened connections is closed, Remoting Lease doesn't work any more
> -------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-541
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-541
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Clebert Suconic
>         Assigned To: Ron Sigal
>            Priority: Critical
>             Fix For: 1.0.1.CR5
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> IF you create two connections, and close the first one, like the following test, Lease doesn't work any more:
> 	      conn1 = cf.createConnection();
> 	      conn1.setClientID("test1");
> 	      conn1.start();
> 	      conn2 = cf.createConnection();
> 	      conn2.setClientID("test2");
> 	      conn2.start();
> 	      conn1.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

        


From jira-events at jboss.com  Wed Sep 20 20:26:55 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:26:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-526)
 JMSRedelivered flag not
 correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28212709.1158798415592.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-526:
-------------------------------------------

    Assignee: Ovidiu Feodorov  (was: Clebert Suconic)

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR5
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:26:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:26:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29579019.1158798416220.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-545:
-------------------------------------------

    Assignee: Ovidiu Feodorov

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Wed Sep 20 20:48:56 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 20:48:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-549) Remoting
 2.2.0.Alpha1 breaks 2 crash tests
Message-ID: <11678719.1158799736606.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remoting 2.2.0.Alpha1 breaks 2 crash tests
------------------------------------------

                 Key: JBMESSAGING-549
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Clebert Suconic
            Priority: Blocker
             Fix For: 1.0.1.CR5


1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest

Error setting up client lease upon performing connect.

javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
	at sun.rmi.transport.Transport$1.run(Transport.java:148)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
	at java.lang.Thread.run(Thread.java:534)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
	at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115)


2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest

Error setting up client lease upon performing connect.

javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
	at sun.rmi.transport.Transport$1.run(Transport.java:148)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
	at java.lang.Thread.run(Thread.java:534)
	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
	at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115)


-- 
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

        


From jira-events at jboss.com  Wed Sep 20 23:30:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Wed, 20 Sep 2006 23:30:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-550) Add JBoss
 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
Message-ID: <5205854.1158809458341.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add JBoss 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
------------------------------------------------------------------------------

                 Key: JBMESSAGING-550
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-550
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Minor




-- 
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

        


From MAILER-DAEMON at lists.jboss.org  Wed Sep 20 23:38:11 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Wed, 20 Sep 2006 23:38:11 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609210338.k8L3cBhd007834@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From MAILER-DAEMON at lists.jboss.org  Wed Sep 20 23:38:26 2006
From: MAILER-DAEMON at lists.jboss.org (MAILER-DAEMON at lists.jboss.org)
Date: Wed, 20 Sep 2006 23:38:26 -0400
Subject: [jboss-jira] Virus intercepted
Message-ID: <200609210338.k8L3cQ72007849@chief.prod.atl2.jboss.com>

A message sent from <MAILER-DAEMON at lists.jboss.org> to
	<jboss-jira at lists.jboss.org>
contained Worm.Mydoom.M and has not been delivered.


From jira-events at jboss.com  Thu Sep 21 00:17:58 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 00:17:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-289) Make service
 container configurable wrt datasource and persistence manager config
Message-ID: <610384.1158812278729.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-289?page=all ]

Ovidiu Feodorov updated JBMESSAGING-289:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)

This fix is useful mostly for clustering testing, so I'll do it while working for the Alpha release.

> Make service container configurable wrt datasource and persistence manager config
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-289
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-289
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>
> Must be made configurable so test suite can be run against different databases with different pm configs

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 00:25:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 00:25:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <28491757.1158812759047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Priority: Blocker  (was: Critical)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 00:41:57 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Thu, 21 Sep 2006 00:41:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-601) Integrate http with
	messaging
Message-ID: <14467485.1158813717043.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate http with messaging
-----------------------------

                 Key: JBREM-601
                 URL: http://jira.jboss.com/jira/browse/JBREM-601
             Project: JBoss Remoting
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.Beta1 (Bluto)
            Reporter: Ron Sigal
         Assigned To: Tom  Elrod
             Fix For: 2.2.0.Beta1 (Bluto)


A few changes need to be made for the http transport to work with JBossMessaging.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 00:48:55 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 00:48:55 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3634) Acknowledgement of
 transacted message in MessageListener should be inside delivery lock
In-Reply-To: <4660406.1157632723860.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5136684.1158814135967.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3634?page=all ]

Adrian Brock updated JBAS-3634:
-------------------------------

    Description: 
The acknowledgement of a transacted message for a MessageListener
should be inside the delivery lock.

Otherwise the addition of the acknowledgement could be competing with other
operations on the session, e.g. commit/rollback/recover.


  was:
The acknowledgement of a transacted message for a MessageListener
should be inside the delivery lock.

Otherwise the addition of the acknowledgement could be competing with other
operations on the session, e.g. commit/rollback/recover.

org.jboss.mq.SpyMessageConsumer::run()

+            // Try to obtain the session delivery lock
+           // This avoids concurrent delivery to message listeners in the same session as per spec
+            boolean gotDeliveryLock = false;
+            while (gotDeliveryLock == false)
+            {

            if (session.transacted)
            {
               // REVIEW: for an XASession without a transaction this will ack the message
               // before it has been processed. Plain message listeners
               // are not supported in a j2ee environment, but what if somebody is trying 
               // to be clever?
               if (trace)
                  log.trace("run() acknowledging message in tx mes=" + mes.getJMSMessageID() + " " + this); 
               session.connection.spyXAResourceManager.ackMessage(session.getCurrentTransactionId(), mes);
            }

-            // Try to obtain the session delivery lock
-            // This avoids concurrent delivery to message listeners in the same session as per spec
-            boolean gotDeliveryLock = false;
-            while (gotDeliveryLock == false)
-            {


> Acknowledgement of transacted message in MessageListener should be inside delivery lock
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-3634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3634
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> The acknowledgement of a transacted message for a MessageListener
> should be inside the delivery lock.
> Otherwise the addition of the acknowledgement could be competing with other
> operations on the session, e.g. commit/rollback/recover.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:04:57 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:04:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3634) Acknowledgement of
 transacted message in MessageListener should be inside delivery lock
In-Reply-To: <4660406.1157632723860.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18791645.1158815097600.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3634?page=all ]

Adrian Brock closed JBAS-3634.
------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

> Acknowledgement of transacted message in MessageListener should be inside delivery lock
> ---------------------------------------------------------------------------------------
>
>                 Key: JBAS-3634
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3634
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> The acknowledgement of a transacted message for a MessageListener
> should be inside the delivery lock.
> Otherwise the addition of the acknowledgement could be competing with other
> operations on the session, e.g. commit/rollback/recover.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:06:56 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:06:56 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3628) Invalid fix for
	JBAS-3573
In-Reply-To: <29130556.1157540489272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19272419.1158815216105.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3628?page=all ]

Adrian Brock closed JBAS-3628.
------------------------------

    Resolution: Done

> Invalid fix for JBAS-3573
> -------------------------
>
>                 Key: JBAS-3628
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3628
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> in case of an exception, both  a PostCommit Task and a PostRollback Task should be added
>          try
>          {
>             if (m.isPersistent())
>                server.getPersistenceManager().remove(m, txId);
>          }
>          catch (Throwable t)
>          {
>             // Something is wrong with the persistence manager,
>             // force a NACK with a rollback/error
>             Runnable task = new RestoreMessageTask(m);
>             TxManager txManager = server.getPersistenceManager().getTxManager();
> +          txManager.addPostCommitTask(txId, task);            
>             txManager.addPostRollbackTask(txId, task);
>             SpyJMSException.rethrowAsJMSException("Error during ACK ref=" + m, 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

        


From jira-events at jboss.com  Thu Sep 21 01:08:58 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:08:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3468) JMS Connection starts
 ping thread
 before ClientID is set resulting in the ClientMonitorInterceptor to close
 the connection after client timeout
In-Reply-To: <11361240.1154691131936.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31810537.1158815338412.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3468?page=all ]

Adrian Brock closed JBAS-3468.
------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

> JMS Connection starts ping thread before ClientID is set resulting in the ClientMonitorInterceptor to close the connection after client timeout
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3468
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3468
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP
>            Reporter: Francis Labaere
>         Assigned To: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> When creating a JMS connection using HTTPConnectionFactory for a user without preconfigured ClientID, mq.Connection starts the ping thread before the ClientID of the Connection  is set (explicitely using setClientID or implicitely).   The ping thread starts pinging the server with ConnectionToken/@ClientID equal to null.
> The ClientMonitorInterceptor adds this ConnectionToken to its clients HashMap.  When the ClientID of the Connection is set (e.g. to XXX) later, the next call to the server will add the updated ConnectionToken to the ClientMonitorInterceptor's clients HashMap with the same SessionID as the previous one.  When the ClientMonitorInterceptor checks timedout clients, it will close the session for the first ConnectionToken.  Subsequent calls to the server will generate exceptions: User session is not valid.
> On the JBoss server, the ClientMonitorInterceptor closes the client with ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Checking for timedout clients.
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.server.ClientMonitorInterceptor] Disconnecting client due to inactivity timeout: ConnectionToken:null/0e9cae0c268a6d4aeb393f40552ce059
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientIL] close()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] getInstance()
> 2006-08-04 11:53:12,261 TRACE [org.jboss.mq.il.http.HTTPClientILStorageQueue] put(HTTPILRequest asynchClose(), String 105)
> 2006-08-04 11:53:12,261 DEBUG [org.jboss.mq.il.http.HTTPClientILStorageQueue] ClientIL #105 has existing storage queue, adding request to it.
> Later (e.g. after sending a JMS message) the SecurityInterceptor checks the connection with the same sessionID ,but different ClientID: ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.security.ServerSecurityInterceptor] Checking receive authorize on ConnectionToken:ID:4/0e9cae0c268a6d4aeb393f40552ce059 subId=-2147483648
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] EXCEPTION : receive: 
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> 2006-08-04 13:17:57,294 TRACE [org.jboss.mq.server.TracingInterceptor] RETURN : receive
> 2006-08-04 13:17:57,294 DEBUG [org.jboss.mq.il.http.servlet.HTTPServerILServlet] Threw an exception of type 'javax.jms.JMSSecurityException' with a message of 'User session is not valid.'  This exception is being propogated to the client as a HTTPILResponse.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] doPost() defers to processRequest, see the parameters in its trace.
> 2006-08-04 13:17:57,404 TRACE [org.jboss.mq.il.http.servlet.HTTPServerILServlet] processRequest(HttpServletRequest org.apache.catalina.connector.RequestFacade at 2bac2b, HttpServletResponse org.apache.catalina.connector.ResponseFacade at 1343c2a)
> On the Client side: following stacktrace is visible
> 13:17:57 [MessageListenerThread - MyTopic] WARN  org.jboss.mq.SpyMessageConsumer - Message consumer closing due to error in listening thread.
> javax.jms.JMSSecurityException: User session is not valid
> 	at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
> 	at org.jboss.mq.server.ClientMonitorInterceptor.receive(ClientMonitorInterceptor.java:231)
> 	at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:579)
> 	at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.processRequest(HTTPServerILServlet.java:204)
> 	at org.jboss.mq.il.http.servlet.HTTPServerILServlet.doPost(HTTPServerILServlet.java:287)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> 	at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:153)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> 	at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:307)
> 	at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:385)
> 	at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:748)
> 	at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:678)
> 	at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:871)
> 	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> 	at java.lang.Thread.run(Thread.java:595)
> mq.Connection should start the ping thread after the ClientID is known.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:10:57 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3620) JBossMQ's
 PersistenceManager
 RecoveryRetries doesn't work if failure is creating the schema
In-Reply-To: <22503210.1157372383786.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3156181.1158815457165.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3620?page=all ]

Adrian Brock closed JBAS-3620.
------------------------------

    Resolution: Done

> JBossMQ's PersistenceManager RecoveryRetries doesn't work if failure is creating the schema
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3620
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3620
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBossMQ's PersistenceManager has a mechanism to retry recovery
> a number of times "RecoveryRetries".
> However, this only applies to the data recovery. If it fails 
> (e.g. due to database or network glitch)
> while checking/creating the database schema
> then no retries are done.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 01:10:57 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 21 Sep 2006 01:10:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3627) Write test to test
 rollback of a NACK in 2PC
In-Reply-To: <22340756.1157539649297.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12187319.1158815457365.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3627?page=all ]

Adrian Brock closed JBAS-3627.
------------------------------

    Resolution: Done

> Write test to test rollback of a NACK in 2PC
> --------------------------------------------
>
>                 Key: JBAS-3627
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3627
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Luc Texier
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to test BasicQueue.acknowledge()
> whether it should also add a PostRollback task for a NACK under a transaction.
> i.e. 
>       // Was it a negative acknowledge??
>       if (!item.isAck)
>       {
>          Runnable task = new RestoreMessageTask(m);
>          server.getPersistenceManager().getTxManager().addPostCommitTask(txId, task);
> +         server.getPersistenceManager().getTxManager().addPostRollbackjTask(txId, task);
>       }
> The  hard part is wrting such a test since it is a normal condition.
> Probably need to use direct invocation on the server invoker ?

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 02:22:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 02:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3117058.1158819721237.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Ovidiu Feodorov updated JBMESSAGING-545:
----------------------------------------

    Priority: Blocker  (was: Major)

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 02:34:01 2006
From: jira-events at jboss.com (Onno de Groote (JIRA))
Date: Thu, 21 Sep 2006 02:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3679) BMP entitybeans cause
 db-deadlocks
Message-ID: <29336818.1158820441651.JavaMail.jira@cloud.prod.atl2.jboss.com>

BMP entitybeans cause db-deadlocks
----------------------------------

                 Key: JBAS-3679
                 URL: http://jira.jboss.com/jira/browse/JBAS-3679
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Transaction Manager
    Affects Versions: JBossAS-3.2.7 Final
         Environment: windows 2003, sun jvm 1.4.2_06, INet Opta JDBC driver 6.04, SQLSERVER 2000
            Reporter: Onno de Groote
         Assigned To: Adrian Brock


when using local-tx datasources with no transactionisolation-level specified, it looks like jboss sets it to repeatable-read or higher. The problem with this situation is that in high concurrency situations, two threads using the same entity-bean ( with or without same primary-key ) cause deadlocks in SQLServer. The reason for this is that de select queries in the findby and ejbload code set S-locks on the indexes in the database, thereby blocking any update query of a different thread. In the situation that thread-1 first performs the findby and ejbload, causing S-locks, after which thread-2 does the same, after which thread-1 tries ejbstore, which blocks because of the S-locks of thread-2. Then thread-2 tries the ejbstore, which in turn is blocked by the S-locks of thread-1. SQLServer detectes a deadlock and selects a deadlock victim and one transaction fails. In this case there should not have been a problem so the transaction-failure is incorrect and only caused by the wrong transactionisolation level

-- 
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

       



From jira-events at jboss.com  Thu Sep 21 02:48:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 02:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-655) Refactor
	@Service beans
In-Reply-To: <30703765.1153251191416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <231379.1158821281612.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-655?page=all ]

Carlo de Wolf resolved EJBTHREE-655.
------------------------------------

    Resolution: Rejected

> Refactor @Service beans
> -----------------------
>
>                 Key: EJBTHREE-655
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-655
>             Project: EJB 3.0
>          Issue Type: Task
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Refactor @Service beans to fix a number of problems:
> * magic methods for lifecycle methods:
>   - create/start/stop/destroy
> * lifecycle methods are not required to be in @Management (MBean) interface.
> * @Management interface is not registered with the ServiceController (Controller in MC land).  It *IS* registered as a regular MBean though.
> * If lifecycle methods exist on @Management interface, they must be intercepted on the container so that the appropriate Controler start/stop is done on the container.  This would mean that you have to specify a <bind> in the Service aspect domain in ejb3-interceptors-aop.xml

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 03:04:01 2006
From: jira-events at jboss.com (warren crossing (JIRA))
Date: Thu, 21 Sep 2006 03:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3680) URLDeployer deploys
 before JAR/WAR/EAR available
Message-ID: <8020433.1158822241606.JavaMail.jira@cloud.prod.atl2.jboss.com>

URLDeployer deploys before JAR/WAR/EAR available
------------------------------------------------

                 Key: JBAS-3680
                 URL: http://jira.jboss.com/jira/browse/JBAS-3680
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Installer
    Affects Versions: JBossAS-4.0.4.GA
         Environment: Linux SCP
            Reporter: warren crossing
         Assigned To: Alex Pinkin


I scp my war into the deployment directory

and I get spewage below.

you must scan the lastmodified to see if it has changed 

if is has changed you must add additional logic..

sleep for 1/2 a second and then check lastmodified again 

that means wait until file is complete!

org.jboss.deployment.DeploymentException: invalid distance code; - nested throwable: (java.util.zip.ZipException: invalid distance code)
        at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.java:374)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.deployment.SubDeployerInterceptorSupport.init(SubDeployerInterceptorSupport.java:119)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.init(SubDeployerInterceptorSupport.java:172)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:87)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy42.init(Unknown Source)
        at org.jboss.deployment.MainDeployer.init(MainDeployer.java:861)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:798)
        at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
        at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy6.deploy(Unknown Source)
        at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
        at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
        at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
Caused by: java.util.zip.ZipException: invalid distance code
        at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
        at java.util.zip.ZipInputStream.read(ZipInputStream.java:139)
        at java.util.jar.JarInputStream.read(JarInputStream.java:171)
        at org.jboss.util.file.JarUtils.unjar(JarUtils.java:300)
        at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.j

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 03:32:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 03:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24003876.1158823921337.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=all ]

Carlo de Wolf updated EJBTHREE-711:
-----------------------------------

        Fix Version/s: EJB 3.0 RC10 - FD
                           (was: EJB 3.0 RC9 - FD)
    Affects Version/s: EJB 3.0 RC9 - FD

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 03:34:01 2006
From: jira-events at jboss.com (Jason T. Greene (JIRA))
Date: Thu, 21 Sep 2006 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25570373.1158824041387.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3678?page=comments#action_12343723 ] 
            
Jason T. Greene commented on JBAS-3678:
---------------------------------------

Yes, I remember this problem. The issue was that the testsuite has a
replacefilter that was applying to everything in resources/webservices,
including binary files. On windows this isn't a problem, but on Unix it
is because of the CRLF -> LF conversion, which corrupts the image file
that is used by this test. The solution is to make the replacefilter
only apply to text files (*.xml, *.wsdl, etc). 

-Jason

JBoss
second
org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
------------------------------------------------------------------------
org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHand
le
org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartI
mp
org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBind
in
org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBin
di
org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP1
1B
org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.t
es
java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:6
4)
org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageD
at
org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataC
on
administrators:
http://www.atlassian.com/software/jira


> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Jason T. Greene
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 04:14:01 2006
From: jira-events at jboss.com (jarkko Lietolahti (JIRA))
Date: Thu, 21 Sep 2006 04:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-357) Add support in Seam
 for intra portlet communication.
Message-ID: <24475927.1158826441399.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support in Seam for intra portlet communication. 
-----------------------------------------------------

                 Key: JBSEAM-357
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-357
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: jarkko Lietolahti
            Priority: Critical


When using Seam in Portal environment make it possible to specify which PortletSession context is used to storage attributes. See forum thread for more information.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 04:26:01 2006
From: jira-events at jboss.com (Thomas Heute (JIRA))
Date: Thu, 21 Sep 2006 04:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12496251.1158827161454.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Thomas Heute resolved JBPORTAL-998.
-----------------------------------

    Resolution: Done

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>         Attachments: eclipse-2.6.patch, eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 04:26:01 2006
From: jira-events at jboss.com (Thomas Heute (JIRA))
Date: Thu, 21 Sep 2006 04:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-998) Eclipse project
 files are not up to date with structure of third party libraries
In-Reply-To: <26546903.1156848199789.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19162236.1158827161648.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-998?page=all ]

Thomas Heute updated JBPORTAL-998:
----------------------------------

    Fix Version/s: 2.4.1 Final
                   2.6.Alpha1

> Eclipse project files are not up to date with structure of third party libraries
> --------------------------------------------------------------------------------
>
>                 Key: JBPORTAL-998
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-998
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.1 Final
>         Environment: Windows XP, Eclipse 3.2
>            Reporter: Sverker Abrahamsson
>         Assigned To: Thomas Heute
>            Priority: Minor
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: eclipse-2.6.patch, eclipse.patch
>
>
> When importing the JBoss portal into workspace there are a lot of unresolved dependancies since the structure on third party libraries has changed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 05:56:04 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Thu, 21 Sep 2006 05:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3674) service
 MetricsLookup dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1853858.1158832564140.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3674?page=comments#action_12343725 ] 
            
abo abo commented on JBAS-3674:
-------------------------------

can you please be a little more specific?

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 05:56:04 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 05:56:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3680) URLDeployer deploys
 before JAR/WAR/EAR available
In-Reply-To: <8020433.1158822241606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2129885.1158832564661.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3680?page=all ]

Dimitris Andreadis closed JBAS-3680.
------------------------------------

    Resolution: Rejected

You need to move the file in the deploy directory atomically, e.g. copy/ftp to a different location in the same filesystem (long operation), then do a move (mv) which is an atomic operation.

> URLDeployer deploys before JAR/WAR/EAR available
> ------------------------------------------------
>
>                 Key: JBAS-3680
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3680
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Installer
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Linux SCP
>            Reporter: warren crossing
>         Assigned To: Alex Pinkin
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> I scp my war into the deployment directory
> and I get spewage below.
> you must scan the lastmodified to see if it has changed 
> if is has changed you must add additional logic..
> sleep for 1/2 a second and then check lastmodified again 
> that means wait until file is complete!
> org.jboss.deployment.DeploymentException: invalid distance code; - nested throwable: (java.util.zip.ZipException: invalid distance code)
>         at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.java:374)
>         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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>         at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
>         at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
>         at org.jboss.deployment.SubDeployerInterceptorSupport.init(SubDeployerInterceptorSupport.java:119)
>         at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.init(SubDeployerInterceptorSupport.java:172)
>         at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:87)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>         at $Proxy42.init(Unknown Source)
>         at org.jboss.deployment.MainDeployer.init(MainDeployer.java:861)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:798)
>         at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:771)
>         at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
>         at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
>         at $Proxy6.deploy(Unknown Source)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
>         at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274)
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225)
> Caused by: java.util.zip.ZipException: invalid distance code
>         at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:140)
>         at java.util.zip.ZipInputStream.read(ZipInputStream.java:139)
>         at java.util.jar.JarInputStream.read(JarInputStream.java:171)
>         at org.jboss.util.file.JarUtils.unjar(JarUtils.java:300)
>         at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.j

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 06:14:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 06:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10242062.1158833641642.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=comments#action_12343727 ] 
            
Carlo de Wolf commented on EJBTHREE-711:
----------------------------------------

First stop:
12:09:01,055 INFO  [ServiceContainer] stop called
java.lang.Exception: STACKTRACE
        at org.jboss.ejb3.service.ServiceContainer.stop(ServiceContainer.java:172)
        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.jboss.ejb3.ServiceDelegateWrapper.stopService(ServiceDelegateWrapper.java:118)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
        at $Proxy0.stop(Unknown Source)
        at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56)
        at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
        at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
        at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
        at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
        at org.jboss.system.ServiceController.doChange(ServiceController.java:633)
        at org.jboss.system.ServiceController.stop(ServiceController.java:457)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy91.stop(Unknown Source)
        at org.jboss.ejb3.JmxKernelAbstraction.uninstallMBean(JmxKernelAbstraction.java:151)
        at org.jboss.ejb3.JmxKernelAbstraction.uninstall(JmxKernelAbstraction.java:178)
        at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:501)
        at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
        at $Proxy0.stop(Unknown Source)
        at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56)
        at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
        at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
        at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
        at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
        at org.jboss.system.ServiceController.doChange(ServiceController.java:633)
        at org.jboss.system.ServiceController.stop(ServiceController.java:457)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy29.stop(Unknown Source)
        at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:469)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.ws.integration.jboss.DeployerInterceptor.stop(DeployerInterceptor.java:122)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy30.stop(Unknown Source)
        at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417)
        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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)


> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 06:14:02 2006
From: jira-events at jboss.com (madan srinivas (JIRA))
Date: Thu, 21 Sep 2006 06:14:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3681) EJB3.0 Session bean
	lookup
Message-ID: <5574956.1158833642890.JavaMail.jira@cloud.prod.atl2.jboss.com>

EJB3.0 Session bean lookup
--------------------------

                 Key: JBAS-3681
                 URL: http://jira.jboss.com/jira/browse/JBAS-3681
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.4.CR2
         Environment: JBoss4.0.4CR2
            Reporter: madan srinivas
         Assigned To: Bill Burke


I get ejb not bound exception when i look up session bean

sessoin bean jndi name is mentioned using annotation in hte code as 

@Stateless
@RemoteBinding(jndiBinding="ejb/remote/FileDetails")

the look up code is 

Properties env = new java.util.Properties();		
		
env.setProperty("java.naming.provider.url", "http://localhost:8080/invoker/JNDIFactory");
env.setProperty("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
env.setProperty("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");
		
InitialContext ctx = new InitialContext(env);
FileDetailsClientBean filesession =  (FileDetailsClientBean)ctx.lookup("ejb/remote/FileDetails");		
filesession.addFileDetails();

Pls help me resolve this and let me know if the code is correct

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 06:14:03 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 06:14:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24368268.1158833643068.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=comments#action_12343728 ] 
            
Carlo de Wolf commented on EJBTHREE-711:
----------------------------------------

Second stop:
12:09:01,086 INFO  [ServiceContainer] stop called
java.lang.Exception: STACKTRACE
        at org.jboss.ejb3.service.ServiceContainer.stop(ServiceContainer.java:172)
        at org.jboss.ejb3.Ejb3Deployment.stop(Ejb3Deployment.java:504)
        at org.jboss.ejb3.Ejb3Module.stopService(Ejb3Module.java:107)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStop(ServiceMBeanSupport.java:315)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:247)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:167)
        at $Proxy0.stop(Unknown Source)
        at org.jboss.system.microcontainer.StartStopLifecycleAction.uninstallAction(StartStopLifecycleAction.java:56)
        at org.jboss.system.microcontainer.ServiceControllerContextAction.uninstall(ServiceControllerContextAction.java:90)
        at org.jboss.dependency.plugins.AbstractControllerContextActions.uninstall(AbstractControllerContextActions.java:58)
        at org.jboss.dependency.plugins.AbstractControllerContext.uninstall(AbstractControllerContext.java:236)
        at org.jboss.dependency.plugins.AbstractController.uninstall(AbstractController.java:723)
        at org.jboss.dependency.plugins.AbstractController.uninstallContext(AbstractController.java:685)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:325)
        at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:190)
        at org.jboss.system.ServiceController.doChange(ServiceController.java:633)
        at org.jboss.system.ServiceController.stop(ServiceController.java:457)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy29.stop(Unknown Source)
        at org.jboss.ejb3.EJB3Deployer.stop(EJB3Deployer.java:469)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
        at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
        at org.jboss.ws.integration.jboss.DeployerInterceptor.stop(DeployerInterceptor.java:122)
        at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.stop(SubDeployerInterceptorSupport.java:196)
        at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:99)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
        at $Proxy30.stop(Unknown Source)
        at org.jboss.deployment.MainDeployer.stop(MainDeployer.java:667)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:638)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:632)
        at org.jboss.deployment.MainDeployer.undeploy(MainDeployer.java:615)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        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.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:266)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:179)
        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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:816)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:417)
        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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
        at sun.rmi.transport.Transport$1.run(Transport.java:153)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
        at java.lang.Thread.run(Thread.java:595)


> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 07:02:03 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 07:02:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11640286.1158836523613.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=comments#action_12343729 ] 
            
Carlo de Wolf commented on EJBTHREE-711:
----------------------------------------

The container is stopped at Ejb3Deployment.java:501 and Ejb3Deployment:504.

It appears that container.stop() is redundant.

Note that Ejb3Deployer.startService & Ejb3Deployer.stopService are very asymetrical. Is this by design?

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 08:01:00 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 08:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-286) Weaken dependencies
 on unreleased MC 2.0
In-Reply-To: <13804037.1158765061202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4316810.1158840060199.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-286?page=all ]

Kabir Khan closed JBAOP-286.
----------------------------

    Resolution: Done

> Weaken dependencies on unreleased MC 2.0
> ----------------------------------------
>
>                 Key: JBAOP-286
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-286
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 21 08:46:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 08:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10744703.1158842761945.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343731 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

-1 has no meaning for the default timeout but the clause should be changed.

The lower level action only understands
  0 == no timeout
  >0 == timeout


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 08:49:00 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 21 Sep 2006 08:49:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16972197.1158842940960.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343732 ] 
            
Mark Little commented on JBTM-116:
----------------------------------

Which lower level? JBossTS understands -1. It means "transactions never time out".

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:00:59 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 09:00:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <13098297.1158843659889.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment:     (was: jboss-aop-jdk50.jar)

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:01:00 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 09:01:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAOP-253) Before release,
 submit the jar to the Messaging team for testing
Message-ID: <29826673.1158843660069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ]

Kabir Khan updated JBAOP-253:
-----------------------------

    Attachment:     (was: jboss-aop.jar)

> Before release, submit the jar to the Messaging team for testing
> ----------------------------------------------------------------
>
>                 Key: JBAOP-253
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-253
>             Project: JBoss AOP
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Kabir Khan
>             Fix For: 2.0.0.alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:03:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 09:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28765978.1158843781347.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343733 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

Okay, just looked at the code again and I missed a step.

Setting the default timeout to 0 means that it defers to the default timeout in the property file.

So
 -1 = don't call the reaper (no timeout)
  0 = don't replace the property file value (i.e. use the property default)
 >0 = timeout

So the code in the mbean should read

public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
{
    if (timeout != 0)
    {
        TxControl.setDefaultTimeout(timeout);
    }
}

Ignore 0 and set the others.


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:15:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 09:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4690573.1158844501152.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343734 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

BTW The lower level was the transaction reaper code :-)

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:18:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 21 Sep 2006 09:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21591802.1158844681427.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343736 ] 
            
Mark Little commented on JBTM-116:
----------------------------------

Yes, but we don't add transactions to the reaper unless they have a non-zero timeout ;-)

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 21 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13474989.1158844861191.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343737 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

Ah but we do in at least one case, which is where the misunderstanding came from ;-)


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:25:58 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Thu, 21 Sep 2006 09:25:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27631007.1158845158458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=all ]

Carlo de Wolf reassigned EJBTHREE-711:
--------------------------------------

    Assignee: Carlo de Wolf

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:37:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <30036724.1158845821227.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343739 ] 
            
Dimitris Andreadis commented on JBAS-3652:
------------------------------------------

Rajesh, working on this?

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:37:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3554) Upgrade JBoss AS to
 use MyFaces 1.1.4
In-Reply-To: <13598507.1156340386344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28240820.1158845821418.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3554?page=all ]

Dimitris Andreadis closed JBAS-3554.
------------------------------------

    Resolution: Done

It's done, I suppose.

> Upgrade JBoss AS to use MyFaces 1.1.4
> -------------------------------------
>
>                 Key: JBAS-3554
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3554
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Stan Silvert
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to upgrade to MyFaces 1.1.4 when it gets released.
> This should fix the problem of not saving server-side state:
> http://issues.apache.org/jira/browse/MYFACES-1296

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:43:00 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 09:43:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <10829529.1158846180693.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343741 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Will get this in today.

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 09:45:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 09:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-9) Remove the dom4j
 dependency from org.jboss.util.state.xml.StateMachineParser
In-Reply-To: <11341338.1158763621358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4600967.1158846301140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-9?page=all ]

Dimitris Andreadis closed JBCOMMON-9.
-------------------------------------

    Resolution: Done

Done

> Remove the dom4j dependency from org.jboss.util.state.xml.StateMachineParser
> ----------------------------------------------------------------------------
>
>                 Key: JBCOMMON-9
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-9
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>    Affects Versions: 1.0.0.CR1
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: 1.0.0.GA, 2.0.0.Beta
>
>
> StateMachineParser is the only class in the common package that has a dependency on dom4j.
> Re-write it so the dom4j dependency is removed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32274466.1158847201350.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3666?page=comments#action_12343744 ] 
            
Dimitris Andreadis commented on JBAS-3666:
------------------------------------------

So the standalone common module does not depend on dom4j anymore. This is currently accessed through snapshot-Branch_1_0, and will be part of jboss-common-1.0.0.GA

The jmx module now uses the jarjar org.jboss.dom4j version of dom4j, bundled in jboss-jmx.jar. The old dom4j lib is removed from JBOSS_HOME/lib.

The latest dom4j.jar lib is copied in JBOSS_HOME/server/all|default/lib, so modules like 'deployment' and 'console' that have minor dependencies on it can use it, plus user code that depended on dom4j will still work.

Updating dom4j / jaxen should now be easily done, if necessary.

> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBXB-85) Add support for
 base64 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23442829.1158847201462.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBXB-85?page=comments#action_12343745 ] 
            
Heiko Braun commented on JBXB-85:
---------------------------------

I migrated the the org.jboss.test.xml.XOPUnitTestCase to the local test suite and added test methods for marshalling/unmarshalling simple xsd:base64Binary declarations.

> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28860513.1158847201583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3666?page=all ]

Dimitris Andreadis closed JBAS-3666.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:00:01 2006
From: jira-events at jboss.com (Heiko Braun (JIRA))
Date: Thu, 21 Sep 2006 10:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBXB-85) Add support for
 base64 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16405029.1158847201812.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-85?page=all ]

Heiko Braun reassigned JBXB-85:
-------------------------------

    Assignee: Alexey Loubyansky

> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:06:01 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Thu, 21 Sep 2006 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
Message-ID: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support EJBContext injection through ejb-jar.xml
------------------------------------------------

                 Key: EJBTHREE-712
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
             Project: EJB 3.0
          Issue Type: Task
    Affects Versions: EJB 3.0 RC10 - FD
            Reporter: Bill Burke
         Assigned To: Carlo de Wolf


Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:19:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 10:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-549) Remoting
 2.2.0.Alpha1 breaks 2 crash tests
In-Reply-To: <11678719.1158799736606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7880735.1158848341198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-549?page=all ]

Clebert Suconic updated JBMESSAGING-549:
----------------------------------------

    Affects Version/s:     (was: 1.0.1.CR4)

It doesn't affect CR4

> Remoting 2.2.0.Alpha1 breaks 2 crash tests
> ------------------------------------------
>
>                 Key: JBMESSAGING-549
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> 1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115)
> 2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115)

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 10:40:00 2006
From: jira-events at jboss.com (Arvinder Singh (JIRA))
Date: Thu, 21 Sep 2006 10:40:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-136) Define a set of EPRs
 for Email, Ftp and Database.
In-Reply-To: <16199470.1157972847765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26434763.1158849600393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-136?page=all ]

Arvinder Singh closed JBESB-136.
--------------------------------

    Resolution: Done

EPRs in xsd format together with basic examples and validation have been added. This task is ongoing and the epr xsds will evolve over time, for now there is a working skeleton with more details to be added

> Define a set of EPRs for Email, Ftp and Database.
> -------------------------------------------------
>
>                 Key: JBESB-136
>                 URL: http://jira.jboss.com/jira/browse/JBESB-136
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Arvinder Singh
>         Assigned To: Arvinder Singh
>             Fix For: 4.0
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> Define a set of EPRs for Email, Ftp and Database. This should follow the current jms skeleton present in the codebase in xml format

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:04:01 2006
From: jira-events at jboss.com (Britt Miner (JIRA))
Date: Thu, 21 Sep 2006 11:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-753) Leaving a
 Superstate does not record a NodeLog
In-Reply-To: <11880179.1158597657146.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4607958.1158851041098.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-753?page=comments#action_12343760 ] 
            
Britt Miner commented on JBPM-753:
----------------------------------

Till then, I've posted a brute force work-around ( http://wiki.jboss.org/wiki/Wiki.jsp?page=Jbpm_SuperStateNodeLogAH ) that gets a Superstate NodeLog recorded for the sake of reporting and statusing performance.

> Leaving a Superstate does not record a NodeLog
> ----------------------------------------------
>
>                 Key: JBPM-753
>                 URL: http://jira.jboss.com/jira/browse/JBPM-753
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions:  jBPM 3.1.2
>            Reporter: Britt Miner
>         Assigned To: Tom Baeyens
>
> Leaving a Superstate should persist a NodeLog, but doesn'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

        


From jira-events at jboss.com  Thu Sep 21 11:06:01 2006
From: jira-events at jboss.com (Thomas Heute (JIRA))
Date: Thu, 21 Sep 2006 11:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPTL-51) Have a different page
 to change password
Message-ID: <24662672.1158851161324.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPTL-51?page=all ]

Thomas Heute updated JBPTL-51:
------------------------------

    Attachment: JBPTL-51.zip

Contribution of Benjamin Lerer

Thanks !

> Have a different page to change password
> ----------------------------------------
>
>                 Key: JBPTL-51
>                 URL: http://jira.jboss.com/jira/browse/JBPTL-51
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>            Reporter: Thomas Heute
>            Priority: Optional
>         Attachments: JBPTL-51.zip
>
>   Original Estimate: 1 hour, 30 minutes
>  Remaining Estimate: 1 hour, 30 minutes
>
> Just to make it more convenient, a different page (than the edit profile page) to change the password would be nice.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:06:01 2006
From: jira-events at jboss.com (Britt Miner (JIRA))
Date: Thu, 21 Sep 2006 11:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-288) Fork/Join and child
 token deactivation
Message-ID: <1165498.1158851161974.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-288?page=comments#action_12343762 ] 
            
Britt Miner commented on JBPM-288:
----------------------------------

For anyone experiencing this problem, I've posted a work-around here http://wiki.jboss.org/wiki/Wiki.jsp?page=Jbpm_EndForkedTokensAH.

> Fork/Join and child token deactivation
> --------------------------------------
>
>                 Key: JBPM-288
>                 URL: http://jira.jboss.com/jira/browse/JBPM-288
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>    Affects Versions: jBPM 3.0
>         Environment: Any
>            Reporter: Lukasz Czekierda
>         Assigned To: Tom Baeyens
>         Attachments: processdefinition.xml, SimpleProcessTest.java
>
>
> Join implementation has incorrectly/no implemented activation of finished child tokens. They remain active till the end of the whole process.  Example from junit test (Wfp03SynchronizationTest.testSynchronizationFirstTokenFirst) works perfectly as long as is unmodified. After adding a few bottom lines and changing a transition in join I get my error. Token.end is called on children and the root token in the LAST state, when finishing the entire process. When in stateX or stateY, the process still reports two active child tokens. 
>  --- 
> "<process-definition>" + 
> " <start-state name='start'>" + 
> " <transition to='fork' />" + 
> " </start-state>" + 
> " <fork name='fork'>" + 
> " <transition name='first' to='one' />" + 
> " <transition name='second' to='two' />" + 
> " </fork>" + 
> " <state name='one'>" + 
> " <transition to='join' />" + 
> " </state>" + 
> " <state name='two'>" + 
> " <transition to='join' />" + 
> " </state>" + 
> " <join name='join'>" + 
> " <transition to='stateX' />" + 
> " </join>" + 
> " <state name='stateX'>" + 
> " <transition to='stateY' />" + 
> " </state>" + 
> " <state name='stateY'>" + 
> " <transition to='end' />" + 
> " </state>" +
> " <end-state name='end' />" + 
> "</process-definition>" 

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:09:00 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 11:09:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
Message-ID: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>

If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
-------------------------------------------------------------------------------------

                 Key: JBREM-602
                 URL: http://jira.jboss.com/jira/browse/JBREM-602
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
         Assigned To: Tom  Elrod
            Priority: Blocker
             Fix For: 2.2.0.Beta1 (Bluto)


this will cause an exception setting up the Timer as the Timer doesn't accept negative values.


This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:18:01 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Thu, 21 Sep 2006 11:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3644) ejbqltosql92compiler
 creates LEFT OUTER JOIN when INNER JOIN would be faster
In-Reply-To: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28417885.1158851881680.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3644?page=all ]

anajavi updated JBAS-3644:
--------------------------

    Attachment: EJBQLToSQL92Compiler.java

Modified version of EJBQLToSQL92Compiler. This version tries to use INNER JOIN where possible. It needs also two boolean fields added to ASTPath:
   public boolean forceLeftJoin;
   public boolean wherePath;

> ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
>            Reporter: anajavi
>         Assigned To: Alexey Loubyansky
>         Attachments: EJBQLToSQL92Compiler.java
>
>
> Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 
> Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
> I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
> I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
> I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
> Example:
> Original EJBQL:
> SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
> Generated SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'
> 10x faster SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
> Thank you.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:23:00 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Thu, 21 Sep 2006 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3644) ejbqltosql92compiler
 creates LEFT OUTER JOIN when INNER JOIN would be faster
In-Reply-To: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1915831.1158852180370.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3644?page=all ]

anajavi updated JBAS-3644:
--------------------------

    Attachment: ASTPath.java

> ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
>            Reporter: anajavi
>         Assigned To: Alexey Loubyansky
>         Attachments: ASTPath.java, EJBQLToSQL92Compiler.java
>
>
> Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 
> Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
> I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
> I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
> I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
> Example:
> Original EJBQL:
> SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
> Generated SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'
> 10x faster SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
> Thank you.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:23:00 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 11:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <182475.1158852180525.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-602?page=comments#action_12343764 ] 
            
Clebert Suconic commented on JBREM-602:
---------------------------------------

There is a default being treated.
But in an unknown situation the default is also set to -1.

I"m still investigating

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:24:58 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 21 Sep 2006 11:24:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1052) Build taking too
 long and moving too many files around.
Message-ID: <12400934.1158852298838.JavaMail.jira@cloud.prod.atl2.jboss.com>

Build taking too long and moving too many files around.
-------------------------------------------------------

                 Key: JBPORTAL-1052
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1052
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Portal Core
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


a 5  minute build is not necessary!

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 11:28:05 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Thu, 21 Sep 2006 11:28:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3644)
 ejbqltosql92compiler creates
 LEFT OUTER JOIN when INNER JOIN would be faster
In-Reply-To: <1510266.1158082055374.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13684849.1158852485454.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3644?page=comments#action_12343765 ] 
            
anajavi commented on JBAS-3644:
-------------------------------

Modified version of compiler works as follows:
1. visiting ASTWhere node sets wherePath=true in all ASTWhere's child paths.
2. visiting ASTOr, ASTNullComparison or ASTIsEmpty causes their child paths to have forceLeftJoin=true
3. When visiting ASTPath compiler checks if wherePath is true and adds join based on forceLeftJoin field. If wherePath is false compiler works as before.
4. If some path has forceLeftJoin set, it cannot be reset to innerjoin

Otherwise the compiler works as before.

Is there something i'm missing or can this be added to default JBoss?

This really boosted performance for us.


> ejbqltosql92compiler creates LEFT OUTER JOIN when INNER JOIN would be faster
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3644
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3644
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: JBoss 4.0.3SP1, Sybase 12.5 (and Sybase 15.0)
>            Reporter: anajavi
>         Assigned To: Alexey Loubyansky
>         Attachments: ASTPath.java, EJBQLToSQL92Compiler.java
>
>
> Ejbqltosql92compiler creates LEFT OUTER JOIN's when INNER JOIN could be used. This leads to bad performance, because database server does table scan instead of using index. 
> Running INNER JOIN instead of LEFT OUTER JOIN gives 10x better performance (0,6s/query vs. 0,06s/query).
> I submitted this as a feature request because it is about performance, not bug. However, this bad performance prevents us from using cmp2.x jdbc2 pm, which we would seriously need.
> I tried to go through ejbqltosql92compiler's source, but could not figure out a clean way to make it use INNER JOIN when joining is caused by a path in WHERE-clause (not containing OR).
> I also tried tweaking RDBMS optimizer and upgrading to newer version, but it did not help.
> Example:
> Original EJBQL:
> SELECT OBJECT(o) FROM Rooli AS o WHERE o.toimipaikka.yritys.id=?1 AND o.rooli.nimi=?2
> Generated SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> LEFT OUTER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> LEFT OUTER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> LEFT OUTER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE  t1_o_toimipaikka_yritys.id = 42447 AND  t2_o_rooli.nimi = 'aaa'
> 10x faster SQL:
> SELECT t0_o.id, t0_o.sahkoposti, t0_o.oletusrooli, t0_o.elinkaaren_pvm, t0_o.elinkaaren_tila, t0_o.fk_henkilo, t0_o.fk_toimipaikka, t0_o.fk_kooditus_rooli, t0_o.meta_fk_creator, t0_o.fk_osoite
> FROM rooli t0_o 
> INNER JOIN kooditus_arvo t2_o_rooli ON t0_o.fk_kooditus_rooli=t2_o_rooli.id 
> INNER JOIN toimipaikka t3_o_toimipaikka ON t0_o.fk_toimipaikka=t3_o_toimipaikka.id 
> INNER JOIN yritys t1_o_toimipaikka_yritys ON t3_o_toimipaikka.fk_yritys=t1_o_toimipaikka_yritys.id 
> WHERE t1_o_toimipaikka_yritys.id = 42447 AND t2_o_rooli.nimi = 'aaa'
> Thank you.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:03:59 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Thu, 21 Sep 2006 12:03:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4209363.1158854639511.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-602?page=comments#action_12343770 ] 
            
Tom  Elrod commented on JBREM-602:
----------------------------------

Only place I can see where the pingPeriod value for the timer would be set to a negative value would be within:

LeasePinger.removeClient(String sessionId)

where it walks through the lease period for all client configs and sees if need to reset the ping period.  I have checked in code change for this to ensure never gets set to negative value.  

Don't know if this is the exact error you are seeing, but only place I can see where it could happen.

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:12:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 12:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1732982.1158855121627.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-602?page=comments#action_12343771 ] 
            
Clebert Suconic commented on JBREM-602:
---------------------------------------

The condition for this to happen was:

Server.leasePeriod was set to -1 (hoping to disable lease)

( 
      //Set lease period to -1 --> this should disable leasing so the state won't be cleared up
      //localServer.setAttribute(ServiceContainer.REMOTING_OBJECT_NAME, "LeasePeriod", "-1");
)


Then lease was enabled on the client, a $PING$ was executed.
Lease=-1 was used as the default LeasePeriod (what is not valid for Timers)

       


> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:27:04 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 12:27:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAOP-288) Unify API used by
 AspectDeployer with AOP 2.0
Message-ID: <16584240.1158856024495.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unify API used by AspectDeployer with AOP 2.0
---------------------------------------------

                 Key: JBAOP-288
                 URL: http://jira.jboss.com/jira/browse/JBAOP-288
             Project: JBoss AOP
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: 1.5.2.GA


The AspectDeployer will be built from Branch_4_0 for both AOP 1.5.x and AOP 2.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

        


From jira-events at jboss.com  Thu Sep 21 12:43:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 12:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11712520.1158856981740.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-602?page=all ]

Clebert Suconic updated JBREM-602:
----------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973336#3973336

Lets use the forum thread to discuss the bug

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 12:58:01 2006
From: jira-events at jboss.com (Michael Voss (JIRA))
Date: Thu, 21 Sep 2006 12:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-603) Servers alternately
 discoverd and detected as gone when using ssl
Message-ID: <31645697.1158857881121.JavaMail.jira@cloud.prod.atl2.jboss.com>

Servers alternately discoverd and detected as gone when using ssl
-----------------------------------------------------------------

                 Key: JBREM-603
                 URL: http://jira.jboss.com/jira/browse/JBREM-603
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: detection
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Michael Voss
         Assigned To: Tom  Elrod
            Priority: Critical


When server uses a ssl sconnector the client discovers the new server and detected it has gone and then again discovered and so on
can try it with classes from package org.jboss.remoting.samples.detection.jndi changing transport to sslsocket or multiplex

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:01:01 2006
From: jira-events at jboss.com (Michael Voss (JIRA))
Date: Thu, 21 Sep 2006 13:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-603) Servers alternately
 discoverd and detected as gone when using ssl
In-Reply-To: <31645697.1158857881121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4529875.1158858061342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-603?page=all ]

Michael Voss updated JBREM-603:
-------------------------------

    Attachment: SSL-Detection.zip

(classses are not in a package)

> Servers alternately discoverd and detected as gone when using ssl
> -----------------------------------------------------------------
>
>                 Key: JBREM-603
>                 URL: http://jira.jboss.com/jira/browse/JBREM-603
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: detection
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Michael Voss
>         Assigned To: Tom  Elrod
>            Priority: Critical
>         Attachments: SSL-Detection.zip
>
>
> When server uses a ssl sconnector the client discovers the new server and detected it has gone and then again discovered and so on
> can try it with classes from package org.jboss.remoting.samples.detection.jndi changing transport to sslsocket or multiplex

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:15:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 21 Sep 2006 13:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1052) Build taking
 too long and moving too many files around.
In-Reply-To: <12400934.1158852298838.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2913328.1158858901354.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1052?page=all ]

Roy Russo resolved JBPORTAL-1052.
---------------------------------

    Resolution: Won't Fix

This is unfixable with the build we have currently.

> Build taking too long and moving too many files around.
> -------------------------------------------------------
>
>                 Key: JBPORTAL-1052
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1052
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> a 5  minute build is not necessary!

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:33:00 2006
From: jira-events at jboss.com (Wenbo Zhu (JIRA))
Date: Thu, 21 Sep 2006 13:33:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-713)
 META-INF/jboss-service.xml
 doesn't apply to POJO service bean  (ie. allow to configure POJO service
 bean attributes at deployment time)
Message-ID: <1614383.1158859980865.JavaMail.jira@cloud.prod.atl2.jboss.com>

META-INF/jboss-service.xml doesn't apply to POJO service bean  (ie. allow to configure POJO service bean attributes at deployment time)
---------------------------------------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-713
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-713
             Project: EJB 3.0
          Issue Type: Bug
          Components: EJB3 Extensions
    Affects Versions: EJB 3.0 RC7 - FD
         Environment: JBoss App Server 4.0.4 GA release.
            Reporter: Wenbo Zhu


META-INF/jboss-service.xml is not used when deploying POJO service bean. Also, the EJB3 guide examples contain a dummy jboss-service.xml under META-INF, which should be cleaned up (if not supported).

As this is not part of ejb3 standards, it could be just a feature request - to allow using descriptor file for configuring mbean attrs.



-- 
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

        


From jira-events at jboss.com  Thu Sep 21 13:44:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Thu, 21 Sep 2006 13:44:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26132842.1158860641069.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3666?page=all ]

Scott M Stark reopened JBAS-3666:
---------------------------------

      Assignee: Scott M Stark  (was: Dimitris Andreadis)
             
The current 4.0 build is failing with errors like:

2006-09-21 10:25:42,343 WARN  [org.jboss.system.ServiceController] Problem starting service jboss.web.deployment:war=invoker.war,id=1836912571
java.lang.NoClassDefFoundError: org/dom4j/DocumentException
	at org.jboss.security.jacc.JBossPolicyConfigurationFactory.<init>(JBossPolicyConfigurationFactory.java:57)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
	at java.lang.Class.newInstance0(Class.java:350)
	at java.lang.Class.newInstance(Class.java:303)
	at javax.security.jacc.PolicyConfigurationFactory.getPolicyConfigurationFactory(PolicyConfigurationFactory.java:91)
	at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:351)
	at org.jboss.web.WebModule.startModule(WebModule.java:83)
	at org.jboss.web.WebModule.startService(WebModule.java:61)
	at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)

This particular case is due to the jboss/common snapshot-Branch_1_0 still having dom4j dependencies? I'm looking into it.



> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:12:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Thu, 21 Sep 2006 14:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3666) Replace the dom4j
 dependency with a jarjar'ed equivalent
In-Reply-To: <25832453.1158604501181.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3441969.1158862321708.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3666?page=all ]

Scott M Stark closed JBAS-3666.
-------------------------------

    Resolution: Done

The problem was the reuse of a snapshot release in the build resulting in the local build repository not being in synch with the version described by this issue. Snapshots are evil.


> Replace the dom4j dependency with a jarjar'ed equivalent
> --------------------------------------------------------
>
>                 Key: JBAS-3666
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3666
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Dimitris Andreadis
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Ofuscate the dom4j classes using jarjar  to avoid these leaking into the user space. The dom4j subset we included in 4.0.4 broke use of xpath from dom4j since it has an explicit dependency on jaxen.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:15:01 2006
From: jira-events at jboss.com (Moises Quinto (JIRA))
Date: Thu, 21 Sep 2006 14:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9213197.1158862501264.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-98?page=comments#action_12343778 ] 
            
Moises Quinto commented on JBTM-98:
-----------------------------------

what is the setup of your test? If I have a single JBoss server talking to oracle then it works fine. When I try the following scenario is when I get the problem (both server 4.0.3 SP1 and JBossts 4.2):

Server1 : starts the global distributed transaction, performs local oracle database operations and calls a server2Bean on server2

// this method has the tx "required" attribute in ejb-jar.xml
performGlobalTx(){
  doSomething(); // do oracle operations
  server2Bean.doSomething(); // call remote jboss Server2
}

Server2: the bean on this server updates the same oracle database:

doSomething(){
   performDBOperations...;
  // here is where I get the exceptions reported in the forum <<<<--------------------here
}


> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:49:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 14:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3682) Upgrade jboss aop to
	1.5.2.GA
Message-ID: <2301715.1158864541102.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade jboss aop to 1.5.2.GA
-----------------------------

                 Key: JBAS-3682
                 URL: http://jira.jboss.com/jira/browse/JBAS-3682
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kabir Khan
         Assigned To: Kabir Khan
             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 21 14:55:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 21 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2409) EJB3 JMS
	Integration
Message-ID: <22040590.1158864901603.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2409?page=comments#action_12343779 ] 
            
William DeCoste commented on JBAS-2409:
---------------------------------------

As of EJB3 RC9, all the legacy EJB3 JMS code has been removed in favor of using the jms resource adaptor -except the code to create temporary queues, which the adaptor does not currently support.

> EJB3 JMS Integration
> --------------------
>
>                 Key: JBAS-2409
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2409
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>         Assigned To: William DeCoste
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to determine whether the legacy JMS MDB integration using ServerSessionPools directly
> needs to be refactored to cover both EJB2.1 and EJB3.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

        


From jira-events at jboss.com  Thu Sep 21 14:55:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 21 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-324) Ethereal plugin for
	JGroups
Message-ID: <25242656.1158864901723.JavaMail.jira@cloud.prod.atl2.jboss.com>

Ethereal plugin for JGroups
---------------------------

                 Key: JGRP-324
                 URL: http://jira.jboss.com/jira/browse/JGRP-324
             Project: JGroups
          Issue Type: Feature Request
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.x


Write a C implementation of an ethereal plugin which understands the JGroups wire format and displays information about the JGroups messages (e.g. sender, receiver, headers) in ethereal.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:55:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Thu, 21 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2409) EJB3 JMS Integration
Message-ID: <19272286.1158864901917.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2409?page=all ]

William DeCoste closed JBAS-2409.
---------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.6.CR1)
       Resolution: Done

> EJB3 JMS Integration
> --------------------
>
>                 Key: JBAS-2409
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2409
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>         Assigned To: William DeCoste
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to determine whether the legacy JMS MDB integration using ServerSessionPools directly
> needs to be refactored to cover both EJB2.1 and EJB3.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

        


From jira-events at jboss.com  Thu Sep 21 14:55:02 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 21 Sep 2006 14:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <19129409.1158864902117.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Ryan Campbell moved ASPATCH-78 to JBAS-3683:
--------------------------------------------

              Project: JBoss Application Server  (was: JBoss AS Patches)
                  Key: JBAS-3683  (was: ASPATCH-78)
    Affects Version/s: JBossAS-4.0.4.GA
                           (was: JBossAS-4.0.4.GA)

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Ryan Campbell
>            Priority: Trivial
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:57:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 21 Sep 2006 14:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <9288223.1158865021293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Ryan Campbell updated JBAS-3683:
--------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Ryan Campbell
>            Priority: Trivial
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 14:57:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 21 Sep 2006 14:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <16553872.1158865021477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Ryan Campbell reassigned JBAS-3683:
-----------------------------------

    Assignee:     (was: Ryan Campbell)

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>            Priority: Trivial
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 15:30:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 15:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAOP-288) Unify API used by
 AspectDeployer with AOP 2.0
In-Reply-To: <16584240.1158856024495.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12908310.1158867001072.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAOP-288?page=all ]

Kabir Khan closed JBAOP-288.
----------------------------

    Resolution: Done

> Unify API used by AspectDeployer with AOP 2.0
> ---------------------------------------------
>
>                 Key: JBAOP-288
>                 URL: http://jira.jboss.com/jira/browse/JBAOP-288
>             Project: JBoss AOP
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: 1.5.2.GA
>
>
> The AspectDeployer will be built from Branch_4_0 for both AOP 1.5.x and AOP 2.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

        


From jira-events at jboss.com  Thu Sep 21 15:33:02 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 15:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <12348861.1158867182342.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343783 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Just the text file should be added? what about doc and pdf? they are all the same.
Should this go in HEAD as well?

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 15:33:02 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 15:33:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <8750843.1158867182690.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3652?page=comments#action_12343785 ] 
            
Rajesh Rajasekaran commented on JBAS-3652:
------------------------------------------

Ah. the task description says just the text file. OK

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 15:36:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Thu, 21 Sep 2006 15:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3682) Upgrade jboss aop to
	1.5.2.GA
In-Reply-To: <2301715.1158864541102.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32172928.1158867361050.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3682?page=all ]

Kabir Khan closed JBAS-3682.
----------------------------

    Resolution: Done

> Upgrade jboss aop to 1.5.2.GA
> -----------------------------
>
>                 Key: JBAS-3682
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3682
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Kabir Khan
>         Assigned To: Kabir Khan
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Thu Sep 21 15:44:00 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 21 Sep 2006 15:44:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3652) Add EULA to
 licenses folder of distribution
Message-ID: <8437007.1158867840825.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3652?page=all ]

Rajesh Rajasekaran resolved JBAS-3652.
--------------------------------------

    Resolution: Done

jboss-release.xml modified to bundle JBossEULA.txt in all distributions

> Add EULA to licenses folder of distribution
> -------------------------------------------
>
>                 Key: JBAS-3652
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3652
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: JBossEULA.doc, JBossEULA.pdf, JBossEULA.txt
>
>
> We need to include the attached EULA text file in all "licenses" folders of
> our distributions. It is an umbrella EULA that does not change the
> fact that our source code is open source...it simply applies a little more
> rigor around use of trademarks and logos as well as Export conditions.
> We do not need	to retrofit this into existing builds, just new builds on an
> ongoing	basis. Ex. JBoss AS 4.0.5 should include it.
> 	 
> 	
>  

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 16:18:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 16:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <33447608.1158869881328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Description: 
Provide a HTTP invoker initial configuration and a working example.
Add the example to docs/examples so it can be used as an integration test.

Reviewed requirements:

1. The messaging client needs to connect to the server over HTTP
2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.


  was:
Provide a HTTP invoker initial configuration and a working example.
Add the example to docs/examples so it can be used as an integration test.


> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 16:30:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 16:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <17990787.1158870601250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91135  (was: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=74846)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 17:13:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 17:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-551) Upgrade JBoss
	Remoting
Message-ID: <11467857.1158873181765.JavaMail.jira@cloud.prod.atl2.jboss.com>

Upgrade JBoss Remoting
----------------------

                 Key: JBMESSAGING-551
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-551
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Clebert Suconic
         Assigned To: Clebert Suconic
             Fix For: 1.0.1.CR5


Upgrade JBoss Remoting to a version containing JBREM-602 fixed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 17:43:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 17:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-547) Upgrade
 JBossSerialization to 1.0.3.GA
In-Reply-To: <24696517.1158689157470.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27518668.1158874981200.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-547?page=all ]

Clebert Suconic closed JBMESSAGING-547.
---------------------------------------

    Resolution: Done

> Upgrade JBossSerialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBMESSAGING-547
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-547
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Minor
>             Fix For: 1.0.1.CR5
>
>
> I will do it as soon as the release is out.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 18:42:57 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 18:42:57 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-551) Upgrade JBoss
	Remoting
In-Reply-To: <11467857.1158873181765.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3051892.1158878577794.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-551?page=all ]

Ovidiu Feodorov closed JBMESSAGING-551.
---------------------------------------

    Resolution: Done

> Upgrade JBoss Remoting
> ----------------------
>
>                 Key: JBMESSAGING-551
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-551
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.0.1.CR5
>
>
> Upgrade JBoss Remoting to a version containing JBREM-602 fixed.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 18:43:03 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 18:43:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-549) Remoting
 2.2.0.Alpha1 breaks 2 crash tests
In-Reply-To: <11678719.1158799736606.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8694616.1158878583024.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-549?page=all ]

Ovidiu Feodorov closed JBMESSAGING-549.
---------------------------------------

    Resolution: Done

> Remoting 2.2.0.Alpha1 breaks 2 crash tests
> ------------------------------------------
>
>                 Key: JBMESSAGING-549
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-549
>             Project: JBoss Messaging
>          Issue Type: Bug
>            Reporter: Ovidiu Feodorov
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> 1) org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashNegativeLeaseTest.testClientCrash(ClientCrashNegativeLeaseTest.java:115)
> 2) org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest
> Error setting up client lease upon performing connect.
> javax.jms.IllegalStateException: Error setting up client lease upon performing connect.
> 	at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N6840474864420126404.java)
> 	at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:202)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:96)
> 	at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:91)
> 	at org.jboss.test.messaging.jms.CreateClientOnServerCommand.execute(CreateClientOnServerCommand.java:77)
> 	at org.jboss.test.messaging.tools.jmx.rmi.LocalTestServer.executeCommand(LocalTestServer.java:695)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer.executeCommand(RMITestServer.java:344)
> 	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> 	at sun.rmi.transport.Transport$1.run(Transport.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> 	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> 	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> 	at java.lang.Thread.run(Thread.java:534)
> 	at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
> 	at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
> 	at org.jboss.test.messaging.tools.jmx.rmi.RMITestServer_Stub.executeCommand(Unknown Source)
> 	at org.jboss.test.messaging.jms.crash.ClientCrashZeroLeaseTest.testClientCrash(ClientCrashZeroLeaseTest.java:115)

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 19:07:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Thu, 21 Sep 2006 19:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1053) WSRP URLs are
 improperly un-escaped in situations where they should be.
Message-ID: <4032852.1158880021204.JavaMail.jira@cloud.prod.atl2.jboss.com>

WSRP URLs are improperly un-escaped in situations where they should be.
-----------------------------------------------------------------------

                 Key: JBPORTAL-1053
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1053
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 21 19:15:07 2006
From: jira-events at jboss.com (Mark Menard (JIRA))
Date: Thu, 21 Sep 2006 19:15:07 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-553) PrePersist
 callback method not called if entity's primery key is null
Message-ID: <2981533.1158880507532.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-553?page=comments#action_12343792 ] 
            
Mark Menard commented on EJBTHREE-553:
--------------------------------------

I'm also having this issue, setting my id in the @PrePersist method, and I'm going to apply Michal's patch to Hibernate to work around it.

I would like to ask though is this the way it is supposed to work? Or should we just not generate ids in the @PrePersist method? 

> PrePersist callback method not called if entity's primery key is null
> ---------------------------------------------------------------------
>
>                 Key: EJBTHREE-553
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-553
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jboss-4.0.4.CR2
>            Reporter: Michal Borowiecki
>
> When an entity is persisted which does not have its primary key set (and it is not annotated with GeneratedValue annotation), the @PrePersist callback method is not invoked. 
> Instead the exception is thrown:
> Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): com.bluemedia.system.User
> 	at org.hibernate.id.Assigned.generate(Assigned.java:33)
> 	at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98)
> 	at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
> 	at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:617)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:591)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:595)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:187)
> 	... 64 more
> This is in conflict with ejb 3.0-pfd spec, which states (sec. 3.4.2) :
> "The PrePersist and PreRemove callback methods are invoked for a given entity before the respective EntityManager persist and remove operations for that entity are executed."
> Since the spec states that EntityManager's persist operation is executed after the PrePersist callback methods, setting the value of the primary key in a PrePersist callback method seems a reasonable use case.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:28:58 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Thu, 21 Sep 2006 20:28:58 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-326) Some queries
 are slower when executed in JBoss EJB3
Message-ID: <3755811.1158884938881.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-326?page=comments#action_12343793 ] 
            
Emmanuel Bernard commented on EJBTHREE-326:
-------------------------------------------

We have discovered an important unefficiency (n**2 class) in HEM flush algorithm, do you happen to have lot's of cascade (even bidirectional ones)?

> Some queries are slower when executed in JBoss EJB3
> ---------------------------------------------------
>
>                 Key: EJBTHREE-326
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-326
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC3
>         Environment: JBoss4.0.3 rc2
>            Reporter: J-C jc
>         Assigned To: Emmanuel Bernard
>
> When a lot of objects have been resolved in the current transaction, queries becomes slow. see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68954&postdays=0&postorder=asc&start=0 for more details.
> More generally, it seems that EJB3 persistence access is slower in JBoss EJB3 compare to access in EJB3 outside of JBoss:
> see http://forum.hibernate.org/viewtopic.php?t=948850

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:31:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Thu, 21 Sep 2006 20:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19180110.1158885061685.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=all ]

Emmanuel Bernard reassigned EJBTHREE-649:
-----------------------------------------

    Assignee: Emmanuel Bernard

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:31:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Thu, 21 Sep 2006 20:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23644986.1158885061920.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343794 ] 
            
Emmanuel Bernard commented on EJBTHREE-649:
-------------------------------------------

We have discovered an important unefficiency (n**2 class) in HEM flush algorithm, do you happen to have lot's of cascade (even bidirectional ones)?

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:47:00 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 20:47:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28294710.1158886020436.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Clebert Suconic reassigned JBMESSAGING-545:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 20:57:01 2006
From: jira-events at jboss.com (Chris Rudd (JIRA))
Date: Thu, 21 Sep 2006 20:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-308) DataModel
 instance changes
 even though the backing list did not when using PAGE scope
In-Reply-To: <29938082.1152829515513.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28541944.1158886621114.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-308?page=comments#action_12343795 ] 
            
Chris Rudd commented on JBSEAM-308:
-----------------------------------

Yes this issue causes the behavior that is described in the thread.

> DataModel instance changes even though the backing list did not when using PAGE scope
> -------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-308
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-308
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.0 beta 1, 1.0 beta 2, 1.0, 1.0.1, 1.1
>            Reporter: Chris Rudd
>
> The outjectDataModel code attempts to determine if the value changed and therefore needs to be re outjected.
> When not using PAGE scope this works fine. When PAGE scope is used it always reports dirty, which causes the value to be outjected. 
> The issue is that if the backing value didnt change, it still gets re-wrapped and outjected instead of just re-outjected. 
> I noticed this when working with an @DataModel, the UIData components im using cache the DataModel to ensure that it doesnt change between the updateValues and the invokeApplication phases. So hwat ends up happening is that in the updateValues phase a property gets set on my component, causing the datamodel to be re-outjected, since the UIData has already cached the original value, it never picks up the "new" one. When I get to the invokeApplication phase and it calls an action method on the component the datamodel that the UIData updated the rowIndex on isnt the same one that seam pulls the rowIndex from to inject the @DataModelSelection.
> I propose the following fix to the 1.0.0 GA code ( removed PAGE scope check from dirty assignment, added else clause to if(dirty) ):
>  private void outjectDataModelList(String name, Object list, ScopeType scope, DataBinder wrapper)
>    {
>       
>       Context context = getDataModelContext(scope);
>       Object existingDataModel = context.get(name);
>       boolean dirty = existingDataModel == null || 
>             !wrapper.getWrappedData(existingDataModel).equals(list); //TODO: delegate to the wrapper to determine equality
>       
>       if ( dirty )
>       {
>          if ( list != null )
>          {
>             context.set( name, wrapper.wrap(list) );
>          }
>          else
>          {
>             context.remove( name );
>          }
>       }
>       // If page scope, outject the existingDataModel even if there was no change
>       else if( scope==ScopeType.PAGE )
>       {
>          context.set( name, existingDataModel );
>       }
>       
>    }

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 21:05:59 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 21:05:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
Message-ID: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>

MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
---------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-552
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Beta1


Logs Attached

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 21:08:00 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 21:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
In-Reply-To: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1964201.1158887280034.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-552?page=all ]

Ovidiu Feodorov updated JBMESSAGING-552:
----------------------------------------

    Attachment: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log

> MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-552
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>         Attachments: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log, MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log
>
>
> Logs Attached

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 21:08:00 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 21 Sep 2006 21:08:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
In-Reply-To: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5202883.1158887280176.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-552?page=all ]

Ovidiu Feodorov updated JBMESSAGING-552:
----------------------------------------

    Attachment: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log

> MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-552
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>         Attachments: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log, MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log
>
>
> Logs Attached

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 22:00:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 22:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5846955.1158890401262.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Clebert Suconic updated JBMESSAGING-545:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973448#3973448

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 22:36:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 21 Sep 2006 22:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-545) Transaction
 edge cases and memory leak
In-Reply-To: <5287947.1158592496070.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28469859.1158892561353.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-545?page=all ]

Clebert Suconic closed JBMESSAGING-545.
---------------------------------------

    Resolution: Done

> Transaction edge cases and memory leak
> --------------------------------------
>
>                 Key: JBMESSAGING-545
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-545
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Tim Fox
>         Assigned To: Clebert Suconic
>            Priority: Blocker
>             Fix For: 1.0.1.CR5
>
>
> There is currently a memory leak in transaction repository since a 2pc transaction branch object is never removed from the repository even on successfully commit or rollback of the transaction.
> We should add code at the end of the Transaction::commit() and Transaction::rollback() methods to remove the transaction from the map (it will only be in the map if it is two phase).
> We do not want to remove the transaction from the map if commit or rollback fails - this is because the transaction manager might retry the commit or rollback.
> Moreover, it is possible the transaction commits correctly on the server side but the invocation fails before it returns to the transaction manager causing the manager to think the branch failed to commit when in fact it did commit.
> In this case the manager may retry the commit, but we will have no record of the branch.
> Therefore if we receive commits for transactions we know nothing about we should return success.

-- 
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

        


From jira-events at jboss.com  Thu Sep 21 23:27:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Thu, 21 Sep 2006 23:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-602) If LeasePeriod is
 not set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13528298.1158895621181.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-602?page=all ]

Tom  Elrod resolved JBREM-602.
------------------------------

    Resolution: Done

> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 00:30:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 00:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3684) References to
	TxManager
Message-ID: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>

References to TxManager
-----------------------

                 Key: JBAS-3684
                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB3
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Kevin Conner
         Assigned To: Bill Burke
            Priority: Critical


The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.

      ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
      ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java

These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 00:35:00 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 00:35:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3685) References to
	TxManager
Message-ID: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>

References to TxManager
-----------------------

                 Key: JBAS-3685
                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Kevin Conner
            Priority: Critical


The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.

   aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java

These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.

Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
===================================================================
--- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
@@ -26,6 +26,7 @@
 import org.jboss.aop.advice.Interceptor;
 import org.jboss.aop.joinpoint.Invocation;
 import org.jboss.logging.Logger;
+import org.jboss.tm.TransactionTimeoutConfiguration;

 /**
  * This interceptor handles transactions for AOP
@@ -174,20 +175,18 @@

       public Object invoke(Invocation invocation) throws Throwable
       {
-         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
          int oldTimeout = 0;

-         if (tm instanceof org.jboss.tm.TxManager)
+         if (tm instanceof TransactionTimeoutConfiguration)
          {
-            txManager = (org.jboss.tm.TxManager)tm;
-            oldTimeout = txManager.getTransactionTimeout();
+            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
          }

          try
          {
-            if (timeout != -1 && txManager != null)
+            if (timeout != -1 && tm != null)
             {
-               txManager.setTransactionTimeout(timeout);
+               tm.setTransactionTimeout(timeout);
             }

             Transaction tx = tm.getTransaction();
@@ -203,9 +202,9 @@
          }
          finally
          {
-            if (txManager != null)
+            if (tm != null)
             {
-               txManager.setTransactionTimeout(oldTimeout);
+               tm.setTransactionTimeout(oldTimeout);
             }
          }
       }
@@ -241,20 +240,18 @@

       public Object invoke(Invocation invocation) throws Throwable
       {
-         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
          int oldTimeout = 0;

-         if (tm instanceof org.jboss.tm.TxManager)
+         if (tm instanceof TransactionTimeoutConfiguration)
          {
-            txManager = (org.jboss.tm.TxManager)tm;
-            oldTimeout = txManager.getTransactionTimeout();
+            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
          }

          try
          {
-            if (timeout != -1 && txManager != null)
+            if (timeout != -1 && tm != null)
             {
-               txManager.setTransactionTimeout(timeout);
+               tm.setTransactionTimeout(timeout);
             }

             Transaction tx = tm.getTransaction();
@@ -277,9 +274,9 @@
          }
          finally
          {
-            if (txManager != null)
+            if (tm != null)
             {
-               txManager.setTransactionTimeout(oldTimeout);
+               tm.setTransactionTimeout(oldTimeout);
             }
          }
       }


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 02:46:06 2006
From: jira-events at jboss.com (J-C jc (JIRA))
Date: Fri, 22 Sep 2006 02:46:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9116192.1158907566186.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343796 ] 
            
J-C jc commented on EJBTHREE-649:
---------------------------------

That's happen when I have a lot of cascade. My solution has to reduce as much as possible this cascade. It improves the performance but it is sometimes a little more complex to implement and bug prone.
When I tried to investigate a little more the problem (http://opensource.atlassian.com/projects/hibernate/browse/HHH-1207), I go into the hibernate flush  and more specificly the flush on collections.
That's not easy to debug, so as just changing the cascade type solve my problem I have stopped investiagtions.

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 02:52:01 2006
From: jira-events at jboss.com (J-C jc (JIRA))
Date: Fri, 22 Sep 2006 02:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-326) Some queries
 are slower when executed in JBoss EJB3
Message-ID: <6946343.1158907921497.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-326?page=comments#action_12343797 ] 
            
J-C jc commented on EJBTHREE-326:
---------------------------------

I had this problem with old release of JBoss EJB3 (rc2). I do not check if it is always true with last release.

Problem was that queries was slower inside JBoss AS than using EJB3 persistence outside of JBoss AS (in a standalone application).  This issue is probably not the same as http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12340482. Problem is probably in the integration of HEM with the JBoss AS.

> Some queries are slower when executed in JBoss EJB3
> ---------------------------------------------------
>
>                 Key: EJBTHREE-326
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-326
>             Project: EJB 3.0
>          Issue Type: Bug
>          Components: EJB3 Extensions
>    Affects Versions: EJB 3.0 RC3
>         Environment: JBoss4.0.3 rc2
>            Reporter: J-C jc
>         Assigned To: Emmanuel Bernard
>
> When a lot of objects have been resolved in the current transaction, queries becomes slow. see http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68954&postdays=0&postorder=asc&start=0 for more details.
> More generally, it seems that EJB3 persistence access is slower in JBoss EJB3 compare to access in EJB3 outside of JBoss:
> see http://forum.hibernate.org/viewtopic.php?t=948850

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 03:55:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 03:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-322) Provide 3 major
 default configurations (udp.xml, tcp.xml and tcp-nio.xml)
In-Reply-To: <7218240.1158479447973.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21183344.1158911701342.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-322?page=all ]

Bela Ban updated JGRP-322:
--------------------------

    Fix Version/s: 2.4
                       (was: 2.2.9 SP4)

> Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)
> -------------------------------------------------------------------------
>
>                 Key: JGRP-322
>                 URL: http://jira.jboss.com/jira/browse/JGRP-322
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> Those configs should be the same in stacks.xml (for the Multiplexer) as well

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 03:55:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 03:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-711) During
 undeployment stop is being called twice
In-Reply-To: <22671080.1158767881077.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31993198.1158911701903.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-711?page=all ]

Carlo de Wolf resolved EJBTHREE-711.
------------------------------------

    Resolution: Done

> During undeployment stop is being called twice 
> -----------------------------------------------
>
>                 Key: EJBTHREE-711
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-711
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> After destroy is called on the container, stop is called again.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 04:13:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 04:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
Message-ID: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>

EvictionPolicyProvider WARN message is noisy and misleading
-----------------------------------------------------------

                 Key: JBCACHE-776
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
            Reporter: Galder Zamarreno
         Assigned To: Manik Surtani


JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
variable to hold eviction policies. The usage of this variable has been deprecated, but 
JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.

Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :

"Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
for 1.2.x backward compatibility and may disappear in future releases."

This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 04:43:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27749429.1158914581319.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno reassigned JBCACHE-776:
----------------------------------------

    Assignee: Galder Zamarreno  (was: Manik Surtani)

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 04:43:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21062870.1158914581498.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno updated JBCACHE-776:
-------------------------------------

    Priority: Minor  (was: Major)

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:01:01 2006
From: jira-events at jboss.com (tbech (JIRA))
Date: Fri, 22 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3399) Transaction
 timeout fires too late
In-Reply-To: <14963189.1153144999957.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10297404.1158915661475.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3399?page=comments#action_12343798 ] 
            
tbech commented on JBAS-3399:
-----------------------------

There is no need to use JBossTM, it is already implemented in standard JTA. In fact it just appeared in 4.0.3, but the main documenation is not up to date. Finally found this: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigDataSources.

<set-tx-query-timeout> - whether to enable query timeout based on the length of time remaining until the transaction times out (default false - NOTE: This was NOT ported to 4.0.x until 4.0.3)

Sorry that I didn't use forum before.

> Transaction timeout fires too late
> ----------------------------------
>
>                 Key: JBAS-3399
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3399
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: tbech
>            Priority: Minor
>
> Transaction timeout is fired in the 'commit' probably. It is far too late in order to really limit the transaction.
> Scenario:
> - do long job in transaction (CMT);
> - job is finished;
> - commit;
> - timeout exception is thrown;
> Doesn't matter what timeout is set, server does whole job (few hours even) and at the end throws exception. Shouldn't container:
> a) throw an error after timeout 
> b) stop the called EJB method ???

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:25:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 05:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1571614.1158917101383.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3597?page=comments#action_12343799 ] 
            
Dimitris Andreadis commented on JBAS-3597:
------------------------------------------

The test is performed against a Branch_3_2 latest server using the following clients:

3.2.6
3.2.7
3.2.8
3.2.8.SP1
3.2.x (latest)
4.0.2
4.0.3
4.0.3.SP1
4.0.4.GA
4.0.x (latest)

Different runs produce different failures, eg.
4.0.4.GA

3.2.8
4.0.0.GA

4.0.4.GA.
4.0.x

3.2.8.SP1
4.0.4.GA.
4.0.x

3.2.8.SP1
4.0.4.GA

The only common denominator seems to be that 4.0.4.GA always fails


> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:25:01 2006
From: jira-events at jboss.com (Andreas Zimmer (JIRA))
Date: Fri, 22 Sep 2006 05:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8800069.1158917101765.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343800 ] 
            
Andreas Zimmer commented on EJBTHREE-649:
-----------------------------------------

To Emmanuel's question on cascading relations: Yes, the scenario was with a Entity Pojo with cascading UNIdirectional relations, BUT the relations have NOT been filled, just a few String attributes got values. So in the concrete test scenario, no relation handling should have been required. 

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:31:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 05:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3325) Remove old code
Message-ID: <13522545.1158917461525.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3325?page=all ]

Dimitris Andreadis updated JBAS-3325:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> Remove old code
> ---------------
>
>                 Key: JBAS-3325
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3325
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: JBoss 4.0.3.SP1
> $ java -version
> java version "1.4.2_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_12-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
> $ java -version
> java version "1.5.0_07"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode, sharing)
>            Reporter: Robert Schroeder
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingJBossBehindAFirewall mentions the parameter "java.rmi.server.hostname" to set if the external host name differs from the local host (e.g. server machine is behind a firewall)
> But org.jboss.web.WebService doesn'r recognize this parameter:
>       String hostname = server.getBindAddress(); // this always returns something, at least "0.0.0.0"!
>       // If not user specified hostname given, then try to determine what it should be
>       if (hostname == null) //this branch is never executed!
>       {
>          // First look for the rmi server name
>          try
>          {
>             hostname = System.getProperty("java.rmi.server.hostname");  // this parameter is not recognized as this branch is never executed
>          }
>          catch (SecurityException e)
>          {
>             // ignore, but don't be silent
>             ThrowableHandler.addWarning(e);
>          }
>          // else use the localhost name
>          if (hostname == null)
>          {
>             try
>             {
>                hostname = InetAddress.getLocalHost().getHostName();
>             }
>             catch (IOException e)
>             {
>                log.error("Failed to get localhost name; ignoring", e);
>             }
>          }
>          if (hostname != null)
>          {
>             setHost(hostname);
>          }
>       }
>       // Host must be set to continue (either by user or detection)
>       String address = getHost();
>       if (address == null)
>          throw new MissingAttributeException("Host");
>       // Set the rmi codebase if it is not already set
>       String codebase = System.getProperty("java.rmi.server.codebase");
>       if (codebase == null)
>       {
>          address = ServerConfigUtil.fixRemoteAddress(address);
>          codebase = "http://" + address + ":" + getPort() + "/";
>          System.setProperty("java.rmi.server.codebase", codebase);
>       }
>       log.info("Using RMI server codebase: " + codebase);
> So the resulting problem is that codebase contains an address which is not reachable from the other side of firewall because "java.rmi.server.hostname" is not recognized (same for "-Djava.rmi.server.useLocalHostname=false" )
> Example:
> JBoss started with parameter set "-Djava.rmi.server.hostname=as2.subdomain1.subdomain2.test.com"
> but (thanks to rmi logging) the proxy objects on client side have codebase set to "http://as2:<port>" and not to "http://as2.subdomain1.subdomain2.test.com:<port>" as expected.
> JBoss 4 runs on a linux machine
> hostname --> "as2"
> hostname -f --> "as2.subdomain1.subdomain2.test.com"

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:34:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 05:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28760284.1158917641311.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3597?page=comments#action_12343801 ] 
            
Dimitris Andreadis commented on JBAS-3597:
------------------------------------------

The reverse tests (4.0-compatibility) that test a variety of clients against a latest Branch_4_0 server, sometimes pass, sometimes produce errors:

Client
3.2.8.SP1
4.0.4.GA

4.0.4.GA
4.0.x (latest)

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:43:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 05:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3679) BMP entitybeans cause
	db-deadlocks
In-Reply-To: <29336818.1158820441651.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13878494.1158918181985.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3679?page=all ]

Adrian Brock closed JBAS-3679.
------------------------------

    Resolution: Rejected
      Assignee:     (was: Adrian Brock)

Wrong.

If you don't specify the isolation, neither does JBoss.
It uses whatever is defined by the driver/database.

This is all explained in the documentation.

> BMP entitybeans cause db-deadlocks
> ----------------------------------
>
>                 Key: JBAS-3679
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3679
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Transaction Manager
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: windows 2003, sun jvm 1.4.2_06, INet Opta JDBC driver 6.04, SQLSERVER 2000
>            Reporter: Onno de Groote
>
> when using local-tx datasources with no transactionisolation-level specified, it looks like jboss sets it to repeatable-read or higher. The problem with this situation is that in high concurrency situations, two threads using the same entity-bean ( with or without same primary-key ) cause deadlocks in SQLServer. The reason for this is that de select queries in the findby and ejbload code set S-locks on the indexes in the database, thereby blocking any update query of a different thread. In the situation that thread-1 first performs the findby and ejbload, causing S-locks, after which thread-2 does the same, after which thread-1 tries ejbstore, which blocks because of the S-locks of thread-2. Then thread-2 tries the ejbstore, which in turn is blocked by the S-locks of thread-1. SQLServer detectes a deadlock and selects a deadlock victim and one transaction fails. In this case there should not have been a problem so the transaction-failure is incorrect and only caused by the wrong transactionisolation level

-- 
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

       



From jira-events at jboss.com  Fri Sep 22 05:49:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 05:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22428953.1158918541184.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3685?page=all ]

Adrian Brock updated JBAS-3685:
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
         Assignee: Kabir Khan

There's no point creating a critical issue if you don't assign it
to a "fix version". :-)

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:55:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Fri, 22 Sep 2006 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-358) Adding
 core.FacesMessages requires JSF libraries to compile component
Message-ID: <21739116.1158918901085.JavaMail.jira@cloud.prod.atl2.jboss.com>

Adding core.FacesMessages requires JSF libraries to compile component
---------------------------------------------------------------------

                 Key: JBSEAM-358
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-358
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


I have this in a Seam component:

    // For error messages
    @In(create=true)
    private FacesMessages facesMessages;


This is org.jboss.seam.core.FacesMessages. It doesn't extend anything from JSF but I still can't compile my Seam component without the JSF stubs on the classpath:

/Users/turin/work/local/lab8/modules/beans/src/auction/beans/PlaceBidImpl.java
    Error:Error:line (112)cannot access javax.faces.application.FacesMessage
file javax/faces/application/FacesMessage.class not found

This is inconvenient because this is the only JSF compile-time dependency in all of my Seam components and I have to add the JSF libs to my compile classpath just for this. I don't really know why this is required... because of the static methods in FacesMessages?

In any case, it would be nice to be able to send JSF messages without binding the component to JSF and I initially thought that this was the usecase for core.FacesMessages in Seam.



-- 
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

        


From jira-events at jboss.com  Fri Sep 22 05:58:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 05:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-325) Priority traffic
 should use separate network
Message-ID: <8147630.1158919081452.JavaMail.jira@cloud.prod.atl2.jboss.com>

Priority traffic should use separate network
--------------------------------------------

                 Key: JGRP-325
                 URL: http://jira.jboss.com/jira/browse/JGRP-325
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.x


Priority traffic, e.g. heartbeats from FD, or JOIN/LEAVE requests should use a separate NIC, possibly connected to a separate network. This would ensure that priority traffic is *not* discarded because of regular replication traffic which clogs the line

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:04:02 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 06:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12937529.1158919442484.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=all ]

Carlo de Wolf updated EJBTHREE-712:
-----------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=91149

> Support EJBContext injection through ejb-jar.xml
> ------------------------------------------------
>
>                 Key: EJBTHREE-712
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC10 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>
> Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:13:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 06:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10281588.1158919981107.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3685?page=comments#action_12343804 ] 
            
Kevin Conner commented on JBAS-3685:
------------------------------------

Apologies.  I created it as critical because I was under the impression that I was supposed to for the 4.0.5 release.

I still have to chase it up with Dimitris.

I promise the next one will have a "fix version" ;-)


> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:16:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5776157.1158920161518.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=comments#action_12343805 ] 
            
Carlo de Wolf commented on EJBTHREE-712:
----------------------------------------

EJB3 core 16.15 paragraph 2

> Support EJBContext injection through ejb-jar.xml
> ------------------------------------------------
>
>                 Key: EJBTHREE-712
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:16:01 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Fri, 22 Sep 2006 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-712) Support
 EJBContext injection through ejb-jar.xml
In-Reply-To: <24653724.1158847561251.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9639442.1158920161714.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-712?page=all ]

Carlo de Wolf updated EJBTHREE-712:
-----------------------------------

        Fix Version/s: EJB 3.0 RC10 - FD
    Affects Version/s: EJB 3.0 RC9 - FD
                           (was: EJB 3.0 RC10 - FD)

> Support EJBContext injection through ejb-jar.xml
> ------------------------------------------------
>
>                 Key: EJBTHREE-712
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-712
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC9 - FD
>            Reporter: Bill Burke
>         Assigned To: Carlo de Wolf
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Spec says you use <resource-env-ref> to do injection of EJBContext into a bean.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:22:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 06:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3684) References to
	TxManager
In-Reply-To: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17022654.1158920521351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3684?page=all ]

Dimitris Andreadis updated JBAS-3684:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3684
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.
>       ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
>       ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java
> These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:28:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
Message-ID: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>

Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
-----------------------------------------------------------------------------------------------------------

                 Key: JBAS-3686
                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Galder Zamarreno
         Assigned To: Dimitris Andreadis


A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
(notice missing / at the end):

      <attribute name="URLs">
         deploy
      </attribute>

leads to the datasource not deploying due to waiting on:

2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'

JBoss deploys this instead:

2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'

The bug is that DefaultDS is an incomplete deployment and the 
URLDeploymentScanner should throw something like this:

17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:28:01 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Fri, 22 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBWEB-61) Apache Tomcat 6.0
In-Reply-To: <21194316.1153309331365.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4623818.1158920881560.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBWEB-61?page=comments#action_12343806 ] 
            
Remy Maucherat commented on JBWEB-61:
-------------------------------------

It should be done now, and all the necessary refinements and accessory components are implemented.

Remaining:
- Docs for Comet API

> Apache Tomcat 6.0
> -----------------
>
>                 Key: JBWEB-61
>                 URL: http://jira.jboss.com/jira/browse/JBWEB-61
>             Project: JBoss Web
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Remy Maucherat
>         Assigned To: Remy Maucherat
>   Original Estimate: 3 weeks
>  Remaining Estimate: 3 weeks
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:40:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 06:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25462935.1158921601446.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343807 ] 
            
Dimitris Andreadis commented on JBAS-3686:
------------------------------------------

Not sure if this is a bug. If you omit the slash (deploy/) it will treat the deploy dir not as a directory to scan, but as a package with subdeployment, and then all strange things start to happen.

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:43:01 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Fri, 22 Sep 2006 06:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3674) service
 MetricsLookup dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26421829.1158921781761.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3674?page=comments#action_12343808 ] 
            
abo abo commented on JBAS-3674:
-------------------------------

i can't find any way to see _all_ invocations or called methods on a server.
this feature is fery useful to identify problems and should be re-introduced even if you can monitor specific mbeans through web-console.

any reason to drop this feature?


> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:43:01 2006
From: jira-events at jboss.com (abo abo (JIRA))
Date: Fri, 22 Sep 2006 06:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3674) service
 MetricsLookup dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20948108.1158921782065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3674?page=all ]

abo abo reopened JBAS-3674:
---------------------------

             

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:46:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 06:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31839915.1158921961367.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343809 ] 
            
Galder Zamarreno commented on JBAS-3686:
----------------------------------------

But it leads to an attempt to deploy a *-ds.xml as if it were
a sub deployment of deploy. If it attempts to deploy it and 
it can't it should say something, otherwise, don't even 
start the deployment.

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 06:52:01 2006
From: jira-events at jboss.com (J-C jc (JIRA))
Date: Fri, 22 Sep 2006 06:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18691548.1158922321892.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343810 ] 
            
J-C jc commented on EJBTHREE-649:
---------------------------------

Just another comment about flush. To be able to implement features such as an audit trail it will be nice to have a public API to know wich objects has been created/modified/deleted in the current transaction and another to know which properties have been changed.
It looks that these informations are the same as the one used for the flush.

This kind of API wil probably be much more efficient than the audit trail on hibernate  Wiki. It is not relevant to that bug, but as it is in the same area ... It will really help (this subject had been discussed on hibernate and EJB3 forums few months ago)  



> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 07:22:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 07:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-326) Run testsuite by
 default with udp.xml, tcp.xml and tcp-nio.xml
Message-ID: <30322123.1158924121306.JavaMail.jira@cloud.prod.atl2.jboss.com>

Run testsuite by default with udp.xml, tcp.xml and tcp-nio.xml
--------------------------------------------------------------

                 Key: JGRP-326
                 URL: http://jira.jboss.com/jira/browse/JGRP-326
             Project: JGroups
          Issue Type: Task
    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

        


From jira-events at jboss.com  Fri Sep 22 07:22:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 07:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-321)
 CloseTest.testShutdown() fails with -Dconfig=tcp.xml
In-Reply-To: <20644013.1158350917305.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18522067.1158924121458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-321?page=all ]

Bela Ban updated JGRP-321:
--------------------------

    Fix Version/s: 2.5
                       (was: 2.4)

> CloseTest.testShutdown() fails with -Dconfig=tcp.xml
> ----------------------------------------------------
>
>                 Key: JGRP-321
>                 URL: http://jira.jboss.com/jira/browse/JGRP-321
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.3 SP1
>            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

        


From jira-events at jboss.com  Fri Sep 22 07:28:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Fri, 22 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-98) Adding padding
 support to Xid for Oracle OCI driver
In-Reply-To: <9761660.1153208531358.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24598479.1158924481252.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-98?page=comments#action_12343811 ] 
            
Jonathan Halliday commented on JBTM-98:
---------------------------------------


The  test case is based on the Oracle sample code from e.g. http://download-uk.oracle.com/docs/cd/A87860_01/doc/java.817/a83724/samapp9.htm#1012235  Using this code as a starting point, you can alter the size of the byte arrays used in the Xid. The test continues to pass even with arrays shorter than 64 bytes.  This would tend to indicate the problem lies elsewhere. If you have an alternative test case that contradicts this, please submit it. It's possible the problem you are seeing is elsewhere in the code and is masked or avoided as a result of altering the array sizes.

> Adding padding support to Xid for Oracle OCI driver
> ---------------------------------------------------
>
>                 Key: JBTM-98
>                 URL: http://jira.jboss.com/jira/browse/JBTM-98
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>
> Plus add it to qualification drivers for DTF.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 07:36:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 07:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14985650.1158924961232.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343813 ] 
            
Dimitris Andreadis commented on JBAS-3686:
------------------------------------------

Again, I don't think it is a scanner problem, because in this case it doesn't scan at all the deploy dir. It just passes the url to the MainDeployer which deployes this as a JAR deployment and then it reports the result.

If better error reporting could be done at some point, let me know. 

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 07:48:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 07:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3686) Incomplete
 Deployment error not
 thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
In-Reply-To: <10976447.1158920881403.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11443311.1158925681254.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3686?page=comments#action_12343814 ] 
            
Adrian Brock commented on JBAS-3686:
------------------------------------

The issue is caused by the following code in MainDeployer:deploy(URL)

      if( sdi.state != DeploymentState.STARTED )
         checkIncompleteDeployments();

In this case, the top level deployment is started (the deploy folder)
so no check is made.

Since there are no other deployments, it never does this code in URLDeploymentScanner:

      // Validate that there are still incomplete deployments
      if (lastIncompleteDeploymentException != null)
      {
         try
         {
            Object[] args = {};
            String[] sig = {};
            getServer().invoke(getDeployer(),
                               "checkIncompleteDeployments", args, sig);
         }
         catch (Exception e)
         {
            Throwable t = JMXExceptionDecoder.decode(e);
            log.error(t);
         }
      }

This just looks broken to me. In this case, there is nothing wrong with the deployment,
the issue is with the MBeans created as part of the deployment process not having
dependencies satisfied.

In my opinion, the MainDeployer should not be automatically
doing any checks for incomplete deployments it should be invoked by the caller
since only it knows whether there are multiple urls that could have some relation.

main.deploy(url1); // creates mbean1
main.deploy(url2); // creates mbean2 that depends on mbean1
main.checkIncompleteDeployments();

In this way, the URLDeploymentScanner should always check for incompleteness
after every scan that deploys or undeploys something.

You could have a helper method in MainDeployer for simple cases,
which is also what should be used by the testsuite (in most cases).

e.g.
MainDeployer::deployAndCheck(URL url)
{
   deploy(url);
   checkIncompleteDeployments();
}

> Incomplete Deployment error not thrown when DefaultDS not deployed (/ missing at the end of deployment URL)
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3686
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3686
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Dimitris Andreadis
>
> A URL deployment attribute like this on jboss.deployment:type=DeploymentScanner,flavor=URL 
> (notice missing / at the end):
>       <attribute name="URLs">
>          deploy
>       </attribute>
> leads to the datasource not deploying due to waiting on:
> 2006-09-22 12:04:07,640 DEBUG [org.jboss.system.ServiceController] waiting in start jboss.jca:service=ManagedConnectionFactory,name=DefaultDS on jboss.jca:service=RARDeployment,name='jboss-local-jdbc.rar'
> JBoss deploys this instead:
> 2006-09-22 12:04:06,062 DEBUG [org.jboss.resource.deployment.RARDeployment] Created jboss.jca:service=RARDeployment,name='deploy#jboss-local-jdbc.rar'
> The bug is that DefaultDS is an incomplete deployment and the 
> URLDeploymentScanner should throw something like this:
> 17:29:03,852 ERROR [URLDeploymentScanner] Incomplete Deployment listing: ......

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 08:09:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 08:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-323) Set shunning to
 false in both FD and GMS
In-Reply-To: <15586805.1158610675069.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10846740.1158926941205.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-323?page=all ]

Bela Ban resolved JGRP-323.
---------------------------

    Resolution: Done

> Set shunning to false in both FD and GMS
> ----------------------------------------
>
>                 Key: JGRP-323
>                 URL: http://jira.jboss.com/jira/browse/JGRP-323
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Optional
>             Fix For: 2.4
>
>
> should be the default, even if no value is set

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:02:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 22 Sep 2006 09:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-144) Add unit tests for
 new EPR and messaging classes.
In-Reply-To: <3775013.1158753481061.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3821076.1158930121320.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-144?page=all ]

Mark Little closed JBESB-144.
-----------------------------

    Resolution: Done

> Add unit tests for new EPR and messaging classes.
> -------------------------------------------------
>
>                 Key: JBESB-144
>                 URL: http://jira.jboss.com/jira/browse/JBESB-144
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 3 days
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-315) Create check list
 of manual tests
In-Reply-To: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24999370.1158930301473.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-315?page=comments#action_12343818 ] 
            
Bela Ban commented on JGRP-315:
-------------------------------

The list is at JGroups/doc/tests/ManualTests.txt

> Create check list of manual tests
> ---------------------------------
>
>                 Key: JGRP-315
>                 URL: http://jira.jboss.com/jira/browse/JGRP-315
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
> - JGroups/doc/tests/GmsTests.txt
> - Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-315) Create check list of
	manual tests
In-Reply-To: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27673704.1158930301608.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-315?page=all ]

Bela Ban updated JGRP-315:
--------------------------

        Fix Version/s: 2.4
                           (was: 2.5)
    Affects Version/s: 2.3 SP1
                           (was: 2.4)

> Create check list of manual tests
> ---------------------------------
>
>                 Key: JGRP-315
>                 URL: http://jira.jboss.com/jira/browse/JGRP-315
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
> - JGroups/doc/tests/GmsTests.txt
> - Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-315) Create check list of
	manual tests
In-Reply-To: <30853957.1158150273417.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21390877.1158930301734.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-315?page=all ]

Bela Ban resolved JGRP-315.
---------------------------

    Resolution: Done

> Create check list of manual tests
> ---------------------------------
>
>                 Key: JGRP-315
>                 URL: http://jira.jboss.com/jira/browse/JGRP-315
>             Project: JGroups
>          Issue Type: Task
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> Check list should be executed before every release by QA. It contains all edge cases that we cannot automate, or when it would be excessively expensive to automate tests, e.g.
> - JGroups/doc/tests/GmsTests.txt
> - Pull-the-plug scenario with UDP, TCP, TCP_NIO

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:05:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-322) Provide 3 major
 default configurations (udp.xml, tcp.xml and tcp-nio.xml)
In-Reply-To: <7218240.1158479447973.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18336529.1158930301883.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-322?page=all ]

Bela Ban resolved JGRP-322.
---------------------------

    Resolution: Done

> Provide 3 major default configurations (udp.xml, tcp.xml and tcp-nio.xml)
> -------------------------------------------------------------------------
>
>                 Key: JGRP-322
>                 URL: http://jira.jboss.com/jira/browse/JGRP-322
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> Those configs should be the same in stacks.xml (for the Multiplexer) as well

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:11:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-327) Certify JGroups 2.2.9
 SP4 with JBossAS 4.0.3 and 4.0.4
Message-ID: <21738393.1158930661117.JavaMail.jira@cloud.prod.atl2.jboss.com>

Certify JGroups 2.2.9 SP4 with JBossAS 4.0.3 and 4.0.4
------------------------------------------------------

                 Key: JGRP-327
                 URL: http://jira.jboss.com/jira/browse/JGRP-327
             Project: JGroups
          Issue Type: Support Patch
    Affects Versions: 2.2.9 SP4
            Reporter: Bela Ban
         Assigned To: Bela Ban
         Attachments: jgroups-all.jar



-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:11:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-327) Certify JGroups 2.2.9
 SP4 with JBossAS 4.0.3 and 4.0.4
In-Reply-To: <21738393.1158930661117.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2672685.1158930661234.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-327?page=all ]

Bela Ban updated JGRP-327:
--------------------------

    Attachment: jgroups-all.jar

> Certify JGroups 2.2.9 SP4 with JBossAS 4.0.3 and 4.0.4
> ------------------------------------------------------
>
>                 Key: JGRP-327
>                 URL: http://jira.jboss.com/jira/browse/JGRP-327
>             Project: JGroups
>          Issue Type: Support Patch
>    Affects Versions: 2.2.9 SP4
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>         Attachments: jgroups-all.jar
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:11:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Fri, 22 Sep 2006 09:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-714) Session objects
 returned by
 injection should implement SessionImplementor in addition to
 o.h.classic.Session
Message-ID: <15947693.1158930661367.JavaMail.jira@cloud.prod.atl2.jboss.com>

Session objects returned by injection should implement SessionImplementor in addition to o.h.classic.Session
------------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-714
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-714
             Project: EJB 3.0
          Issue Type: Bug
          Components: EJB3 Extensions
    Affects Versions: EJB 3.0 RC9 - FD
            Reporter: Emmanuel Bernard
            Priority: Minor


Hibernate internally can cast a session object to
org.hibernate.classic.Session (subinterface of org.hibernate.Session)
org.hibernate.engine.SessionImplementor

This is especially useful when using the DetachedCriteria API

So at least org.jboss.ejb3.entity.TransactionScopedHibernateSession should implement it

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:31:00 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:31:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-328)
 MultiplexerTest.testStateTransferWithReconnect() has leftover threads if
 run with -Dstack=tcp
Message-ID: <33065949.1158931860965.JavaMail.jira@cloud.prod.atl2.jboss.com>

MultiplexerTest.testStateTransferWithReconnect() has leftover threads if run with -Dstack=tcp
---------------------------------------------------------------------------------------------

                 Key: JGRP-328
                 URL: http://jira.jboss.com/jira/browse/JGRP-328
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:31:01 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Fri, 22 Sep 2006 09:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-649) Query
 Performance within
 transaction decreasing progressively when using default FlushModeType.AUTO
In-Reply-To: <16671165.1152786675717.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20575377.1158931861559.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-649?page=comments#action_12343822 ] 
            
Emmanuel Bernard commented on EJBTHREE-649:
-------------------------------------------

Interceptor do what you want (onFlushDirty)

> Query Performance within transaction decreasing progressively when using default FlushModeType.AUTO
> ---------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-649
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-649
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>         Environment: WinXP SP2, Oracle 9i Enterprise Rel. 9.2.0.1.0, JBoss 4.0.4GA, EJB3.0 RC8-FD
>            Reporter: Andreas Zimmer
>         Assigned To: Emmanuel Bernard
>
> Query Performance within a Transaction is progressively decreasing when working with EJB3.0 default FlushModeType.AUTO:
> 20 queries/reads within transaction - 10 msecs average per query/read 
> 1000 (same as before) queries/reads within transaction - 130 msecs average per query/read (factor 13+) 
> With FlushModeType.COMMIT query performance within the same scenario ist constant at expected 10 msecs but FlushModeType.COMMIT imposes restrictions which our projects can't cope with. We need updates within transaction being visible in subsequent queries of the same transaction.
> The case is explained in some detail in the JBoss Forum Thread as provided in JBoss Forum Reference.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:39:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Fri, 22 Sep 2006 09:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JGRP-328)
 MultiplexerTest.testStateTransferWithReconnect() has leftover threads if
 run with -Dstack=tcp
In-Reply-To: <33065949.1158931860965.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13603075.1158932341075.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-328?page=all ]

Bela Ban updated JGRP-328:
--------------------------

        Fix Version/s: 2.5
                           (was: 2.4)
    Affects Version/s: 2.4
                           (was: 2.3 SP1)

> MultiplexerTest.testStateTransferWithReconnect() has leftover threads if run with -Dstack=tcp
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-328
>                 URL: http://jira.jboss.com/jira/browse/JGRP-328
>             Project: JGroups
>          Issue Type: Bug
>    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

        


From jira-events at jboss.com  Fri Sep 22 09:42:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 09:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-777) FileCacheLoader
 can return null
 for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
Message-ID: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>

FileCacheLoader can return null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
------------------------------------------------------------------------------------------------------

                 Key: JBCACHE-777
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
            Reporter: Galder Zamarreno
         Assigned To: Manik Surtani
            Priority: Minor


FileCacheLoader can return a null value for get(fqn) which goes against the JavaDoc 
requirements for that method:

 /**
    * Returns all keys and values from the persistent store, given a fully qualified name.
    *
    * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
    * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
    * implementations should be checked for compliance with the behaviour expected.
    *
    * @param name
    * @return Map<Object,Object> keys and values for the given node. Returns
    * null if the node is not found.  If the node is found but has no
    * attributes, this method returns an empty Map.
    * @throws Exception
 */

If a get(fqn) operation occurrs before a put and the node (directory) does not exist, FCL returns 
null when it should return an empty Map.

If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
following misleading warning message is logged:

10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:49:01 2006
From: jira-events at jboss.com (Jonathan Halliday (JIRA))
Date: Fri, 22 Sep 2006 09:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
Message-ID: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>

warning with TransactionManager interface in JTS with external TM
-----------------------------------------------------------------

                 Key: JBTM-128
                 URL: http://jira.jboss.com/jira/browse/JBTM-128
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
            Reporter: Jonathan Halliday
         Assigned To: Mark Little


When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:

2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
java.lang.NullPointerException
        at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
        at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)

This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.

Test code to reproduce warning:
        System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
        System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
        ORB myORB = ORB.getInstance("ServerSide");
        OA myOA = OA.getRootOA(myORB);
        myORB.initORB(args, null);
        myOA.initOA();
        javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
        transactionManager.begin();
        transactionManager.commit();


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1338) Thread Pool
 improvements on the client
Message-ID: <7974366.1158933121618.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1338?page=all ]

Adrian Brock closed JBAS-1338.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Thread Pool improvements on the client
> --------------------------------------
>
>                 Key: JBAS-1338
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1338
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> The thread usage on the client needs to be improved.
> The users of threads are:
> 1) The invocation layers for message delivery
> 2) The message listeners to wait for messages
> These should be combinded to use a single thread pool.
> There is no need for a message listener to hold a thread while it is waiting for a message.
> It can add itself to a registry which is then used by delivery to invoke the correct listener
> when a message arrives.
> In fact, by spec the listeners should register themselves with the session and the session
> deliver the messages (single threadedly - is that a word? :-).

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1339) Persistence Manager
	Improvements
Message-ID: <27806050.1158933121762.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1339?page=all ]

Adrian Brock closed JBAS-1339.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Persistence Manager Improvements
> --------------------------------
>
>                 Key: JBAS-1339
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1339
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> There are a number of improvements that can be made to the persistence manager.
> This should really be done by writing a new version that can then be optionally used while
> it is experimental.
> 1) Make use of the datasource mappings - similar what has been done for the EJB timer
> 2) The use of the JTA transaction is unnecessary since we are the only one in the transaction branch. The tranaction still needs suspending so we are isolated from any wrapping transacton.
> 3) Make use of build writes to the database
> This can be used for transactional sessions where multiple messages are processed
> But it could also be used where people want to relax the absolute requirement that
> messages are persisted in return for some performance improvement.
> 4) A general review/rewrite of where the persistence manager is invoked from the
> server with an aim to improve performance.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1340) Lazily Loading Queues
Message-ID: <20625884.1158933121970.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1340?page=all ]

Adrian Brock closed JBAS-1340.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Lazily Loading Queues
> ---------------------
>
>                 Key: JBAS-1340
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1340
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> This is a major change that is the last obstacle to JBossMQ scalability.
> The idea is that messages will only be loaded into the server when the destination is activated
> and then only part of the messages are loaded (enough to deal with the current throughput).
> An attempt was made to do this and committed on Branch JBoss_3_2_5_JBossMQ_Lazy but the
> work was abandoned. It does not deal with the more difficult problems.
> In any case, the BasicQueues should be talking directly with the PersistenceManager.
> In fact, I would favour that the BasicQueue implementation is actually pluggable and
> determined by the PM to allow better optimization between these two important layers.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1337) Thread Pool
 improvements on the server
Message-ID: <1445350.1158933122272.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1337?page=all ]

Adrian Brock closed JBAS-1337.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Thread Pool improvements on the server
> --------------------------------------
>
>                 Key: JBAS-1337
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1337
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>   Original Estimate: 6 weeks
>  Remaining Estimate: 6 weeks
>
> There are a number of different components on the server that use thread pools.
> 1) Invocation Layers
> 2) Client Consumer for delivering messages
> 3) Scheduled delivery/message expiration
> These need to be combined to share threads and minimize context switching where possible.
> The thread pool should be based on the BasicThreadPool from jboss-common

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:52:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1343) ReadAhead and DUPS_OK
 message acknowledgement
Message-ID: <25982339.1158933122558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1343?page=all ]

Adrian Brock closed JBAS-1343.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> ReadAhead and DUPS_OK message acknowledgement
> ---------------------------------------------
>
>                 Key: JBAS-1343
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1343
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>
> Performance can be improved by sending mulitple messages in one request to the client
> when they are using a MessageListener.
> Similary, there is no implementation of DUPS_OK message acknowledgement, which would
> reduce the number of network requests required to acknowledge receipt of messages.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1585) Enhance Queue
	throughput
Message-ID: <12788238.1158933301658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1585?page=all ]

Adrian Brock closed JBAS-1585.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Enhance Queue throughput
> ------------------------
>
>                 Key: JBAS-1585
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1585
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Ivelin Ivanov
>
> > -----Original Message-----
> > From: Adrian Brock
> > Sent: Monday, March 14, 2005 2:35 PM
> > To: Ivelin Ivanov
> > Cc: Stan Silvert; Neal Byrd; The Core; Rebecca Goldstein
> > Subject: RE: JMS Reference
> > 
> ...
> > I know you can get about x8 improvement in JBossMQ just by adding
> > some simple flow control.
> > 
> > Instead of doing the "one in, one out" policy on the message cache
> > when memory is tight (i.e. move some old messages to disk to make
> > room for the new messages)
> > I did a simple test instead  with
> > Thread.sleep(1000);
> > to slow down the senders and let the receivers clear some memory.
> > 
> > The message throughput went from 1 million messages/hour to 8 million.
> > I did this test around JBoss-3.0.7 time when the performance was
> > very poor.
> > 
> > I discarded the idea as too simplistic since the mechanism
> > requires blocking server threads. But it does show JBossMQ
> > could easily be improved if we had the motivation/resources
> > to work on the performance without degrading its reliability.
> >

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2444) Keeping Ordering
 after message NACK
Message-ID: <3463139.1158933301865.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2444?page=all ]

Adrian Brock closed JBAS-2444.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Keeping Ordering after message NACK
> -----------------------------------
>
>                 Key: JBAS-2444
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2444
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>
> There is a common FAQ about how to keep message ordering in the event of failure (i.e. a NACK or transaction rollback).
> JMS gives no such guarantees.
> However, we could give that guarantee at the expense of throughput.
> Basically what we need to do is not allow anybody to receive() a message until the single message (or group of messages
> in the same transaction) that has already been received is either nacked or acked.
> Once the nack (rollback) comes from the client that has the "checked out" message it will be reinserted back into the Queue
> at the top of the list and then we allow the next receive() to run. 
> Meaning it always the nacked message and can't get any other message until the top message is acked.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2492) Add an
 removeReceiver() to the receive(long timeout) processing
Message-ID: <3156424.1158933302002.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2492?page=all ]

Adrian Brock closed JBAS-2492.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Add an removeReceiver() to the receive(long timeout) processing
> ---------------------------------------------------------------
>
>                 Key: JBAS-2492
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2492
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>
> Currently if the receive(long) times out, the receiver is left as waiting for a message on the server.
> This doesn't cause any semantic problems, but it can lead to an unnecessary
> deliver/nack lifecyle if there is no subsequent receive() request and the receiver is not closed.
> It would be better to have the option for receive(long) to issue an removeReceiver
> when it stops waiting.
> However, this requires an incompatible change to the IL - there is currently no such method in the interface.
> It would also need to be implementated carefully to avoid a race condition with
> connection.start/stop().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:55:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1333) connectionFailure
Message-ID: <19481376.1158933302432.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1333?page=all ]

Adrian Brock closed JBAS-1333.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> connectionFailure
> -----------------
>
>                 Key: JBAS-1333
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1333
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Adrian Brock
>
> The connectionFailure invocation from the IL layer needs to pass through the interceptor
> rather than just invoking on the destination manager.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2583) Potential for runaway
 allocation of Connection objects
Message-ID: <26040635.1158933482057.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ]

Adrian Brock closed JBAS-2583.
------------------------------

    Resolution: Done

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Potential for runaway allocation of Connection objects
> ------------------------------------------------------
>
>                 Key: JBAS-2583
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2583
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Natalia Kowalczyk
>
> org.jboss.mq.Connection class uses a singleton  EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. 
> Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-2583) Potential for
 runaway allocation of Connection objects
Message-ID: <1208889.1158933482216.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ]

Adrian Brock reopened JBAS-2583:
--------------------------------

             

> Potential for runaway allocation of Connection objects
> ------------------------------------------------------
>
>                 Key: JBAS-2583
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2583
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Natalia Kowalczyk
>
> org.jboss.mq.Connection class uses a singleton  EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. 
> Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2583) Potential for runaway
 allocation of Connection objects
Message-ID: <19697332.1158933482445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2583?page=all ]

Adrian Brock closed JBAS-2583.
------------------------------

    Resolution: Deferred

> Potential for runaway allocation of Connection objects
> ------------------------------------------------------
>
>                 Key: JBAS-2583
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2583
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Natalia Kowalczyk
>
> org.jboss.mq.Connection class uses a singleton  EDU.oswego.cs.dl.util.concurrent.ClockDaemon to handle pinging of open connections. When connection is opened a ping task is scheduled by inserting into EDU.oswego.cs.dl.util.concurrent.Heap structure maintained internally by ClockDaemon. When connection is closed, its ping task is marked as canceled and subsequently extracted from the Heap by a single thread maintained internally by ClockDaemon. 
> Inserting into Heap structure can be performed by many threads (as part of opening a connection) but extracting is only done by a single thread (in ClockDeamon). As Heap.extract() is a little slower then Heap.insert(), under sufficient system load, ClockDeamon thread may fall behind in its job of removing canceled ping tasks (corresponding to closed connections). If the load on a system persists sufficiently long, JVM will run out of memory because of the canceled ping tasks that ClockDaemon can't extract fast enough.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2464) Support JMSX
	properties
Message-ID: <24885789.1158933482630.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2464?page=all ]

Adrian Brock closed JBAS-2464.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Support JMSX properties
> -----------------------
>
>                 Key: JBAS-2464
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2464
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Look at supporting other JMSX properties in JBossMQ

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:02 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Fri, 22 Sep 2006 09:58:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13235554.1158933482829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3685?page=all ]

Kabir Khan resolved JBAS-3685.
------------------------------

    Resolution: Done

org.jboss.tm.TxManager is needed when running in older versions of JBoss. I have hidden the details in TxManagerTimeoutReader if running in an old version of JBoss. If TransactionTimeoutConfiguration is available, the new mechanism is used via the TransactionTimeoutConfigurationReader.

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 09:58:03 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 09:58:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1342) Message Serialization
Message-ID: <19069242.1158933483177.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1342?page=all ]

Adrian Brock closed JBAS-1342.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Message Serialization
> ---------------------
>
>                 Key: JBAS-1342
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1342
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: JBAS-1342-SpyTextMessage.zip
>
>
> The message body does not need to be deserialized on the server.
> It could just be retained as byte[]
> This will avoid unnecessary Object serialiation at the transport and persistent layer
> inside the server.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:01:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1345) Clustered Invocation
	Layer
Message-ID: <849376.1158933662723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1345?page=all ]

Adrian Brock closed JBAS-1345.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Clustered Invocation Layer
> --------------------------
>
>                 Key: JBAS-1345
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1345
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Clustered Invocation Layer
> 1) Transportation of the cluster view to the client.
> 2) Persistent connections that allows the server to recover the client's state after a failure.
> Both these together will mean the client can transparently failover after a server failure.
> The persistent connections could be used without clustering where the client waits for server recovery.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1348) Message Selector
	Performance
Message-ID: <11684304.1158933841413.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1348?page=all ]

Adrian Brock closed JBAS-1348.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Message Selector Performance
> ----------------------------
>
>                 Key: JBAS-1348
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1348
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Improving Message Selector Performance
> It is a common anti-pattern for users to set up a contested queue
> where multiple receivers try to take messages based on a message selector.
> In most circumstances a Topic is what they should be using.
> But there is a circumstance where a Topic does not work as required,
> that is when a message matches many of the receiver's selector but you
> only want one receiver to process the message (it doesn't matter which).
> The problem is that when a receiver does not match a message towards
> the top of a large Queue (or none at all). The operation to find a message
> or discover there are no messages is very expensive. It is read and skip.
> This can be even worse when the bottom of the queue has been moved out
> to disk by the MessageCache.
> The solution is to provide "an index" over a particular property,
> e.g.
> <mbean code="org.jboss.mq.server.jmx.Queue"
> 	 name="jboss.mq.destination:service=Queue,name=A">
>     <optimized-selector>JMSMessageID</optimized-selector>
>     <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
> </mbean>
> This configuration should be passed via the BasicQueueParameters to the BasicQueue.
> NOTE: This is irrevelent for Topics. Topics run their selector before the message is added
> to the subscription, anything not matching the selector is dropped.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1300) Non-Remote JMS HA
Message-ID: <14139178.1158933841678.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1300?page=all ]

Adrian Brock closed JBAS-1300.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Non-Remote JMS HA
> -----------------
>
>                 Key: JBAS-1300
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1300
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.6 Final
>            Reporter: Andrew Oliver
>            Priority: Minor
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> It should be possible to use JMS on all servers in a cluster with HA enabled.  Meaning:
> 1. Database as a store.  Everyone node uses shared DB.
> 2. JMS_MESSAGES table includes node name
> 3. In the event of group membership changes another node picks up the old node's messages
> 4. JMS Client proxy autofails to another node

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1891) Allow chunking of
 message during recovery
Message-ID: <32784474.1158933842190.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1891?page=all ]

Adrian Brock closed JBAS-1891.
------------------------------

    Fix Version/s: JBossAS-4.0.4.GA
       Resolution: Done

This was already done in 4.0.4,
see RecoveryMessagesChunk here:
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQJDBC2Persistence

> Allow chunking of message during recovery
> -----------------------------------------
>
>                 Key: JBAS-1891
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1891
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.1 Final,  JBossAS-4.0.2RC1, JBossAS-4.0.1 SP1, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>             Fix For: JBossAS-4.0.4.GA
>
>
> Allow messages to be loaded in "chunks" during the recovery process.
> Need to discuss/understand how this can be done where it requires vendor specific processing,
> e.g. see the top level problem for the MySQL issue.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:04:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1349) Message Bridge
Message-ID: <33512335.1158933841538.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1349?page=all ]

Adrian Brock closed JBAS-1349.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Message Bridge
> --------------
>
>                 Key: JBAS-1349
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1349
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Implementation of a MessageBridge.
> ----------------------------------
> This is a proxy that allows messages to be sent to one JMS server
> and then forwarded to the real destination.
> To the senders this looks like a plain queue or topic.
> This is the simplist implementation, more performant implementations are possible:
> 1) Implement the bridge as a new destination type within JBossMQ
> 2) It will behave similarly to a Queue but will not accept external receivers.
> 3) On a background thread (inside a JTA transaction) 
> take some messages from the queue and send them to the real destination.
> 4) The background thread should automatically recover from a failed connection
> and retry at configurable intervals. Similarly it should keep retrying if
> the connection cannot be instantiated at initial startup.
> This is similar to what the MDB does.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2120) JBossMQ should use the
 <type-mapping> from the DataSource
Message-ID: <24079609.1158934021375.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2120?page=all ]

Adrian Brock closed JBAS-2120.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> JBossMQ should use the <type-mapping> from the DataSource
> ---------------------------------------------------------
>
>                 Key: JBAS-2120
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2120
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions:  JBossAS-4.0.3RC1
>            Reporter: Adrian Brock
>            Priority: Minor
>
> Currently JBossMQ's 
> JDBC2 persistence manager (http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQJDBC2Persistence)
> JDBC statemanager (http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQStateJDBC)
> have their SQL configured through a big map of system properties.
> This means that you need different configurations for each backend DB.
> See docs/examples/jms or http://www.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB
> Instead, we should use the <type-mapping> from the DataSource which uses the standardjbosscmp-jdbc.xml
> to map queries to the database.
> The only configuration required, would then be
> * The DataSource
> * Table Names
> * Column Names
> with default names for each.
> This should be done as a "fork", e.g. create a JDBC4 
> since we still want to support people with the old configurations.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3035) Can't proxy JMS
 Queues with org.springframework.jndi.JndiObjectFactoryBean
Message-ID: <25126133.1158934021777.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3035?page=all ]

Adrian Brock closed JBAS-3035.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Can't proxy JMS Queues with org.springframework.jndi.JndiObjectFactoryBean
> --------------------------------------------------------------------------
>
>                 Key: JBAS-3035
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3035
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1
>         Environment: SpringFramework 1.2.7
>            Reporter: Marian Noga
>            Priority: Minor
>
> Proxying of mq destinations is impossible because of lack of Interface for SpyDestination.class
> Even proxying with CGLib won't work because SpyDestination.class has no public constructor.
> Following configuration:
> <bean id="deadLetterQueue" class="org.springframework.jndi.JndiObjectFactoryBean">
> <property name="jndiName" value="queue/DLQ" />
> <property name="cache" value="false" />
> <property name="proxyInterface" value="javax.jms.Queue" />
> </bean>	
> produces output:
> org.springframework.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ; nested exception is javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ; nested exception is javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ
> javax.jms.InvalidDestinationException: Destination is not an instance of SpyDestination QUEUE.DLQ
> at org.jboss.mq.SpyMessageProducer.send(SpyMessageProducer.java:225)
> at org.jboss.mq.SpyMessageProducer.send(SpyMessageProducer.java:212)
> at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:519)
> at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:504)
> at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479)
> at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:432)
> at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477)
> at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> changing proxyInterface to: javax.jms.Destination
> Code:
> <bean id="responseQueue" class="org.springframework.jndi.JndiObjectFactoryBean" lazy-init="false">
> <property name="jndiName" value="queue/konektor_out" />
> <property name="cache" value="false" />
> <property name="proxyInterface" value="javax.jms.Destination" />
> </bean>	
> produces following output:
> java.lang.ClassCastException: $Proxy1
> at org.jboss.mq.SpySession.createProducer(SpySession.java:657)
> at org.springframework.jms.core.JmsTemplate.doCreateProducer(JmsTemplate.java:807)
> at org.springframework.jms.core.JmsTemplate.createProducer(JmsTemplate.java:788)
> at org.springframework.jms.core.JmsTemplate.doSend(JmsTemplate.java:498)
> at org.springframework.jms.core.JmsTemplate$2.doInJms(JmsTemplate.java:479)
> at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:432)
> at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477)
> at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543)
> can anyone tell is it possible to change behaviour of this code:
> SpyMessageProducer.class
> if (destination == null || (destination instanceof SpyDestination) == false)
>          throw new InvalidDestinationException("Destination is not an instance of SpyDestination " + destination); 	
> if SpyDestination was an interface in the code above, everything would be fine.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1347) Improved management
Message-ID: <3179707.1158934021894.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1347?page=all ]

Adrian Brock closed JBAS-1347.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Improved management
> -------------------
>
>                 Key: JBAS-1347
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1347
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> There are a number of areas in JBossMQ that could be better exposed for management.
> The main one is the ClientConsumers.
> This would allow an admin to break a connection with a client and also see stats at the client level.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-1346) JDBC StateManager
Message-ID: <26190183.1158934022379.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1346?page=all ]

Adrian Brock closed JBAS-1346.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> JDBC StateManager
> -----------------
>
>                 Key: JBAS-1346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1346
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-3.2.7 Final, JBossAS-4.0.1 Final
>            Reporter: Adrian Brock
>            Priority: Minor
>
> The JDBC StateManager should have operations to create/delete users and subscriptions in the
> database, just like the old File StateManager did.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:02 2006
From: jira-events at jboss.com (Johnny Healey (JIRA))
Date: Fri, 22 Sep 2006 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1054) Invalid HTML in
	divRenderer
Message-ID: <31885108.1158934022590.JavaMail.jira@cloud.prod.atl2.jboss.com>

Invalid HTML in divRenderer
---------------------------

                 Key: JBPORTAL-1054
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1054
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.4 Final
         Environment: CentOS release 4.4 (Final), jdk1.5.0_06
            Reporter: Johnny Healey
         Assigned To: Julien Viet


Minimize/Maximize buttons have urls containing unescaped ampersands.

"&windowstate=minimized" should read "&amp;windowstate=minimized"

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:07:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:07:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3377) Multiple JMS
 subscriber performance in same VM
Message-ID: <10669113.1158934022809.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3377?page=all ]

Adrian Brock closed JBAS-3377.
------------------------------

    Resolution: Deferred

Closing features that are (or will be) implemented in JBoss Messaging.
http://jira.jboss.com/jira/browse/JBMESSAGING

If anybody wants to provide a patch that implements these,
the issue can be reopened.

Duplicates of these issues will be closed
unless they provide an implementation/patch.

Patches should first be discussed in the
development forum:
http://www.jboss.com/index.html?module=bb&op=viewforum&f=153
if there isn't already a forum link attached to this issue.

> Multiple JMS subscriber performance in same VM
> ----------------------------------------------
>
>                 Key: JBAS-3377
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3377
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: floe fliep
>            Priority: Optional
>
> Consider the following JMS publish/subscribe setup in JB AS 4.0.4GA:
> - one JMS topic publisher running in the AS VM
> - several JMS subscribers to the same topic, running on several threads in one client VM, sharing a single TopicConnection
> While debugging through the JBoss AS 4.0.4GA code, it seems, and as far I was able to see, that the AS sends for each message sent through the TopicPublisher.publish(msg) several identical instances of org.jboss.mq.ReceiveRequest over the network connection, i.e. as many instances as we have subscriptions on the client side. This induces considerable network overhead with larger messages any many clients.
> One workaround to it is to make a client-side construction where there is only subscriber consuming messages, which in its turn distributes them locally. But this feels a bit like building your own JMS.
> Would there be a way to improve this or is this related to constraints imposed by the JMS spec.?

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:10:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 22 Sep 2006 10:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1053) WSRP URLs are
 improperly un-escaped in situations where they should be.
In-Reply-To: <4032852.1158880021204.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5363944.1158934201179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1053?page=all ]

Chris Laprun resolved JBPORTAL-1053.
------------------------------------

    Resolution: Done

> WSRP URLs are improperly un-escaped in situations where they should be.
> -----------------------------------------------------------------------
>
>                 Key: JBPORTAL-1053
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1053
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Chris Laprun
>         Assigned To: Chris Laprun
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:14:05 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:14:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-754) job scheduler
	persistence
Message-ID: <29801175.1158934445422.JavaMail.jira@cloud.prod.atl2.jboss.com>

job scheduler persistence
-------------------------

                 Key: JBPM-754
                 URL: http://jira.jboss.com/jira/browse/JBPM-754
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
            Reporter: Tom Baeyens
         Assigned To: Tom Baeyens
            Priority: Critical
             Fix For: jBPM 3.2 alpha 2


some unexplainable hibernate problem while trying to lock jobs for execution:

16:08:22,843 [main] DEBUG GraphElement : event 'task-create' on 'Task(clean ceiling)' for 'Token(/)'
16:08:22,875 [main] DEBUG GraphElement : executing action 'CreateTimerAction(dc9766)'
16:08:22,875 [main] DEBUG GraphElement : event 'timer-create' on 'Task(clean ceiling)' for 'Token(/)'
16:08:22,875 [main] DEBUG GraphElement : event 'after-signal' on 'StartState(979f67)' for 'Token(/)'
16:08:22,875 [main] DEBUG Services : executing default save operations
16:08:22,875 [main] DEBUG HibernateSaveOperation : saving process instance
16:08:22,875 [main] DEBUG SaveLogsOperation : flushing logs to logging service.
16:08:22,890 [main] DEBUG CascadeSaveOperation : cascading save of 'org.jbpm.graph.exe.ProcessInstance at ffd135'
16:08:22,890 [main] DEBUG JbpmContext : closing JbpmContext
16:08:22,890 [main] DEBUG Services : closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 6d2380
16:08:22,890 [main] DEBUG DbPersistenceService : committing hibernate transaction
16:08:22,890 [main] DEBUG DbPersistenceService : closing hibernate session
16:08:22,890 [main] DEBUG Services : closing service 'tx': org.jbpm.tx.TxService at 159780d
16:08:22,890 [main] DEBUG Services : closing service 'scheduler': org.jbpm.scheduler.db.DbSchedulerService at d8ca48
16:08:22,890 [main] DEBUG Services : closing service 'logging': org.jbpm.logging.db.DbLoggingService at c8570c
16:08:23,218 [main] DEBUG JobExecutor : starting thread group 'JbpmJobExector'...
16:08:23,218 [main] DEBUG JobExecutor : starting new job executor thread 'JbpmJobExector:192.168.1.100:1'
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG JbpmContextInfo : creating jbpm context with service factories '[tx, message, scheduler, logging, persistence, authentication]'
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG JbpmContext : creating JbpmContext
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG DbPersistenceServiceFactory : creating persistence service
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG DbPersistenceService : creating hibernate session
16:08:23,218 [main] DEBUG AbstractDbTestCase : going to sleep for 200 millis, waiting for the job executor to process more jobs
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG DbPersistenceService : beginning hibernate transaction
16:08:23,218 [JbpmJobExector:192.168.1.100:1] DEBUG JobExecutorThread : querying for acquirable job...
16:08:23,375 [JbpmJobExector:192.168.1.100:1] DEBUG JobExecutorThread : trying to obtain a lock for 'timer(ceiling-timer,org.jbpm.taskmgmt.exe.TaskTimerExecutionDbTest$PlusPlus,16:08:22,875)'
16:08:23,406 [JbpmJobExector:192.168.1.100:1] ERROR AssertionFailure : an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session)
org.hibernate.AssertionFailure: collection was not processed by flush(), role=org.jbpm.taskmgmt.def.Task.events
	at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:183)
	at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:328)
	at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
	at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
	at org.jbpm.job.executor.JobExecutorThread.acquireJobs(JobExecutorThread.java:125)
	at org.jbpm.job.executor.JobExecutorThread.run(JobExecutorThread.java:54)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:16:04 2006
From: jira-events at jboss.com (Johnny Healey (JIRA))
Date: Fri, 22 Sep 2006 10:16:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1055)
 minimize/maximize causes portlet to return to initial state
Message-ID: <2682348.1158934564986.JavaMail.jira@cloud.prod.atl2.jboss.com>

minimize/maximize causes portlet to return to initial state
-----------------------------------------------------------

                 Key: JBPORTAL-1055
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1055
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Server
    Affects Versions: 2.4 Final
         Environment: CentOS release 4.4 (Final), jdk1.5.0_06
            Reporter: Johnny Healey
         Assigned To: Julien Viet


This has been noticed in a handful of custom portlets, but can be duplicated in the "event test" page that ships with the portal.  "Test Event A" can change the color of the text in "Test Event B", but minimizing or maximizing "Test Event B" causes the text to return to the original color, black.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 22 Sep 2006 10:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21486061.1158934861130.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3685?page=comments#action_12343848 ] 
            
Kevin Conner commented on JBAS-3685:
------------------------------------

This is a better solution than the one I proposed but there is one flaw in it :-)

The TxTimeoutReaderFactory will only return the TransactionTimeoutConfigurationReader or NullTransactionTimeoutConfigurationReader and never returns the TxManagerTimeOutReader.

You may want to change this ;-)

Thanks for making the change so quickly.

Kev


> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:24:11 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 22 Sep 2006 10:24:11 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-552)
 MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails
 on race condition
In-Reply-To: <31742591.1158887159095.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23534394.1158935051358.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-552?page=comments#action_12343849 ] 
            
Clebert Suconic commented on JBMESSAGING-552:
---------------------------------------------

I have executed org.jboss.test.messaging.jms.MessageConsumerTest::testRedeliveryToCompetingConsumerOnSubscription in loop and successfully executed. (5000 iterations). So.. at this point this is a can't reproduce bug status.

Maybe you some other idea to reproduce this.





> MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription() fails on race condition
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-552
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-552
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>         Attachments: MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription-remote.log, MessageConsumerTest.testRedeliveryToCompetingConsumerOnSubscription.log
>
>
> Logs Attached

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:26:04 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-744) unify and improve the
 messaging and scheduler implementation
In-Reply-To: <11413941.1157122183945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22073665.1158935164306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-744?page=all ]

Tom Baeyens closed JBPM-744.
----------------------------

    Resolution: Done

new implementation is done.  

But there is one known critical problem with the new implementation still open: JBPM-754

> unify and improve the messaging and scheduler implementation
> ------------------------------------------------------------
>
>                 Key: JBPM-744
>                 URL: http://jira.jboss.com/jira/browse/JBPM-744
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 1
>
>
> * unify the scheduler and messaging implementation around the notion of a job
> * add support for multiple concurrent threads competing for job execution.  synchronization is to be done by acquiring locks.  acquiring the locks is done with optimistic locking so that it also works for hsqldb

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:26:04 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-617) keep the
 processdefinition.xml in the database
Message-ID: <32525203.1158935164442.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-617?page=all ]

Tom Baeyens updated JBPM-617:
-----------------------------

    Fix Version/s: jBPM 3.2 alpha 2
                       (was: jBPM 3.2 alpha 1)

> keep the processdefinition.xml in the database
> ----------------------------------------------
>
>                 Key: JBPM-617
>                 URL: http://jira.jboss.com/jira/browse/JBPM-617
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>    Affects Versions: jBPM 3.1, jBPM 3.2 alpha 1, jBPM 3.1.1,  jBPM 3.1.2
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2, jBPM 3.1.3
>
>
> the processdefinition.xml source should be added as a file when a process is deployed.
> this file filtering behaviour should be configurable.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:33:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1485) JMS ResourceAdapter
 makes unnecessary temporary delete requests
Message-ID: <18185789.1158935581290.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1485?page=all ]

Adrian Brock updated JBAS-1485:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> JMS ResourceAdapter makes unnecessary temporary delete requests
> ---------------------------------------------------------------
>
>                 Key: JBAS-1485
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1485
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 SP1
>            Reporter: Adrian Brock
>            Priority: Optional
>             Fix For: JBossAS-4.0.6.CR1
>
>
> The JMS ResourceAdaptor keeps track of temporaries created on a connection
> (org.jboss.resource.adapter.jms.JMSSessionFactoryImpl)
> and deletes them.
> This is because we cannot expect the real JMS implementation to do this
> because the connection is pooled and not closed.
> However, if the user is deleting the temporaries themselves
> (good practice in terms of resource usage),
> the JMS ResourceAdapter does not know about this
> and tries to repeat the delete at connection.close();
> Solution:
> Add some wrapping processing for the temporary queues and topics
> so we can trap temporary.delete(). That way we will know we don't
> need to do it on close()
> IMPORTANT: Invocations like send() or JMSMessage.setJMSReplyTo will
> also need to trap these destinations to do the necessary wrapping/unwrapping.
> It is also possible to retrieve a temporary destination with Session.createQueue/Topic.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:33:01 2006
From: jira-events at jboss.com (Kabir Khan (JIRA))
Date: Fri, 22 Sep 2006 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3685) References to
	TxManager
In-Reply-To: <18529611.1158899700028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30593466.1158935581446.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3685?page=comments#action_12343851 ] 
            
Kabir Khan commented on JBAS-3685:
----------------------------------

Good catch, I've fixed it

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3685
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3685
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: Kabir Khan
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following class contains direct references to org.jboss.tm.TxManager. These references prevent JBossTS being used as a replacement for TxManager.
>    aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> These should be changed to refer to the TransactionTimeoutConfiguration interface instead of TxManager.
> Index: aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java
> ===================================================================
> --- aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (revision 57055)+++ aspects/src/main/org/jboss/aspects/tx/TxInterceptor.java    (working copy)
> @@ -26,6 +26,7 @@
>  import org.jboss.aop.advice.Interceptor;
>  import org.jboss.aop.joinpoint.Invocation;
>  import org.jboss.logging.Logger;
> +import org.jboss.tm.TransactionTimeoutConfiguration;
>  /**
>   * This interceptor handles transactions for AOP
> @@ -174,20 +175,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -203,9 +202,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }
> @@ -241,20 +240,18 @@
>        public Object invoke(Invocation invocation) throws Throwable
>        {
> -         org.jboss.tm.TxManager txManager = (org.jboss.tm.TxManager)tm;
>           int oldTimeout = 0;
> -         if (tm instanceof org.jboss.tm.TxManager)
> +         if (tm instanceof TransactionTimeoutConfiguration)
>           {
> -            txManager = (org.jboss.tm.TxManager)tm;
> -            oldTimeout = txManager.getTransactionTimeout();
> +            oldTimeout = ((TransactionTimeoutConfiguration)tm).getTransactionTimeout();
>           }
>           try
>           {
> -            if (timeout != -1 && txManager != null)
> +            if (timeout != -1 && tm != null)
>              {
> -               txManager.setTransactionTimeout(timeout);
> +               tm.setTransactionTimeout(timeout);
>              }
>              Transaction tx = tm.getTransaction();
> @@ -277,9 +274,9 @@
>           }
>           finally
>           {
> -            if (txManager != null)
> +            if (tm != null)
>              {
> -               txManager.setTransactionTimeout(oldTimeout);
> +               tm.setTransactionTimeout(oldTimeout);
>              }
>           }
>        }

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:33:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1908) listMessageCounter
 issue with JMS
 subscriptions containing certain message selector characters
Message-ID: <1428265.1158935581923.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1908?page=all ]

Adrian Brock updated JBAS-1908:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> listMessageCounter issue with JMS subscriptions containing certain message selector characters
> ----------------------------------------------------------------------------------------------
>
>                 Key: JBAS-1908
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1908
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Windows XP Professional, JDK1.4.2_06, JBoss 4.0.2
>            Reporter: Jaco Joubert
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: DestinationManager.txt, DestinationMBeanSupport.txt, listCounter.jar, MessageCounter.txt, test-topic-service.xml
>
>
> When the message selector query for a subscription to a JMS topic looks someting like "field in ('A', 'B', 'C')", two failures occur on JMS MBeans:
> 1.  The listMessageCounter operation on jboss.mq:service=DestinationManager fails with a NumberFormatException:
> Caused by: java.lang.NumberFormatException: For input string: " 'ghi'"
>   at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>   at java.lang.Integer.parseInt(Integer.java:468)
>   at java.lang.Integer.parseInt(Integer.java:518)
>   at org.jboss.mq.server.jmx.DestinationManager.listMessageCounter(DestinationManager.java:477)
>   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:324)
>   at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>   ... 44 more
> This is because the getCounterAsString() method is used on the MessageCounter to get the details and then traversed with
> a StringTokenizer tokenizing on commas, but the subscription name also contains commas in this case.
> 2.  The listMessageCounter operation on jboss.mq.destination:name=[topicName],service=Topic works, but the resulting HTML
>     table has some of the selector values populating the counter columns.  The problem is because of the same issue as above.
>     
> This can be reproduced by following these steps:
> 1.  Startup a JBoss4.0.2 with default configuration.
> 2.  Deploy the attached 'test-topic-service.xml'.  This will create a JMS topic called 'counterTestTopic'.
> 3.  Run the attached client (source included in jar).  The only jar needed on classpath is the 'jbossall-client.jar':
>     java -cp "[path]\jbossall-client.jar;.\listCounter.jar" za.co.jdj.jbossmq.testcounter.TestListCounter
>     This will do the following:
>     3.1.  Connect to the JMS server running locally.
>     3.2.  Create a publisher and durable subscriber on the 'counterTestTopic' already deployed.
>           The subscriber has a message selector in the format already described
>     3.3.  Invoke the listMessageCounter operation on jboss.mq:service=DestinationManager, printing the error.
>     3.4.  Wait for the client to look at the html table created by the topic in a browser.
>     3.5.  Remove the subscription and exit.
>     
> Suggested fixes for the problem includes:
> 1.  Add a getDestinationTypeDescription() method to org.jboss.mq.server.MessageCounter.  (See MessageCounter.txt attached)
> 2.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationManager to not use the getCounterAsString() method
>     on org.jboss.mq.server.MessageCounter, but rather extract the values itself for the html table.
>     (See the DestinationManager.txt file attached).
> 3.  Change the listMessageCounter method on org.jboss.mq.server.jmx.DestinationMBeanSupport to do the same as above.
>     (See the DestinationMBeanSupport.txt file attached).

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:36:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3484) non portable JDK
 dependant clasess (sun.**)
In-Reply-To: <23337773.1154968092604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20152787.1158935761310.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3484?page=all ]

Adrian Brock updated JBAS-3484:
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

This task needs updating to say what has been done for 4.0.5
and what will be deferred until 4.0.6

> non portable JDK dependant clasess (sun.**)
> -------------------------------------------
>
>                 Key: JBAS-3484
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3484
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Security
>    Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.0.4.GA
>            Reporter: Andrew Oliver
>             Fix For: JBossAS-4.0.5.GA
>
>
> We should not be using sun.** classes in tests or in code.   they are naughty and break working on non Sun JDKs.
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -i "sun.misc.BASE64Encoder" '{}' ';'
>       sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc.BASE64Encoder" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:   /** Compare Util.encodeBase64 against the sun misc class
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * Eliminates dependency on sun.misc.Base64Encoding,
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * (it's an access exception to load sun.misc.* classes
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.io" '{}' ';'
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:         sun.io.CharToByteUTF8 conv = new sun.io.CharToByteUTF8();
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:      } catch ( sun.io.MalformedInputException e ) {
> [andy at localhost jboss-4.0.x]$
> Moreover the 

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:36:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Fri, 22 Sep 2006 10:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-638) renamed configuration
 property mail.smtp.host to jbpm.mail.smtp.host
Message-ID: <15185182.1158935761441.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-638?page=all ]

Tom Baeyens closed JBPM-638.
----------------------------

    Resolution: Done

> renamed configuration property mail.smtp.host to jbpm.mail.smtp.host
> --------------------------------------------------------------------
>
>                 Key: JBPM-638
>                 URL: http://jira.jboss.com/jira/browse/JBPM-638
>             Project: JBoss jBPM
>          Issue Type: Task
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>            Priority: Minor
>             Fix For: jBPM 3.2 alpha 1
>
>
> this is a minor issue since email support has not been released yet.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:36:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3632) Too early checking
 of not closing connections
In-Reply-To: <10803421.1157628643891.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14196274.1158935761598.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3632?page=all ]

Adrian Brock updated JBAS-3632:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> Too early checking of not closing connections
> ---------------------------------------------
>
>                 Key: JBAS-3632
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3632
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> In the case where a transaction is ended early,
> e.g. JBossTM rollsback transactions at a timeout immediately,
> the cached connection manager is firing connection not closed events.
> This is because the ejb is still in the invocation with the connection open
> but the transaction synchronization is fired by the rollback/timeout.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:45:03 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 22 Sep 2006 10:45:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3674) service MetricsLookup
 dont show invocations
In-Reply-To: <27428784.1158745081872.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6362560.1158936303414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3674?page=all ]

Adrian Brock closed JBAS-3674.
------------------------------

    Resolution: Out of Date

Help requests belong in the forums.

> service MetricsLookup dont show invocations
> -------------------------------------------
>
>                 Key: JBAS-3674
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3674
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-3.2.7 Final
>         Environment: Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
> jdk1.5.0_06
> Intel Xeon CPU
>            Reporter: abo abo
>
> on 3.0.6 i see lot of invocations in MetricsLookup service but in 3.2.7 field is always blank, no information given. same configuration both servers.
> metrics-service.xml:
> =============================================================
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE server>
> <!-- $Id: metrics-service.xml,v 1.1 2004/05/31 08:40:40 u07286 Exp $ -->
> <server>
>   <classpath codebase="lib"
>              archives="jboss.jar"/>
>   <!-- ==================================================================== -->
>   <!-- Metrics Service                                                    -->
>   <!-- ==================================================================== -->
>   <mbean code="org.jboss.ejb.plugins.MetricsLookup"
>           name="jboss:service=MetricsLookup">
>           <attribute name="SanityInterval">120000</attribute>
>           <attribute name="AlarmProcess">/app/jboss-3.2.7/bin/rec_stackdump</attribute>
>           <attribute name="EjbPattern">*</attribute>
>           <attribute name="MethodPattern">*</attribute>
>           <attribute name="ShowParams">true</attribute>
>   </mbean>
> </server>
> =============================================================

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:54:05 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 22 Sep 2006 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBREM-602) If LeasePeriod is not
 set and if enableLease==true leasePeriod assumes negative value
In-Reply-To: <12624167.1158851340659.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16452111.1158936845345.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-602?page=all ]

Clebert Suconic closed JBREM-602.
---------------------------------


> If LeasePeriod is not set and if enableLease==true leasePeriod assumes negative value
> -------------------------------------------------------------------------------------
>
>                 Key: JBREM-602
>                 URL: http://jira.jboss.com/jira/browse/JBREM-602
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Tom  Elrod
>            Priority: Blocker
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> this will cause an exception setting up the Timer as the Timer doesn't accept negative values.
> This issue is a Blocker for Messaging, hence why I set this issue as Blocker.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 10:54:05 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 22 Sep 2006 10:54:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3687) Test case for Custom
 Principal Propagation
Message-ID: <29849048.1158936845481.JavaMail.jira@cloud.prod.atl2.jboss.com>

Test case for Custom Principal Propagation
------------------------------------------

                 Key: JBAS-3687
                 URL: http://jira.jboss.com/jira/browse/JBAS-3687
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Security
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


As indicated in the forum thread, there seems to be an issue with the propagation of caller principal (that is of type Custom Principal).  There is a claim that the principal that is propagated happens to be of type SimplePrincipal.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 11:02:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 22 Sep 2006 11:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3687) Test case for
 Custom Principal Propagation
In-Reply-To: <29849048.1158936845481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30940460.1158937321831.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3687?page=comments#action_12343854 ] 
            
Anil Saldhana commented on JBAS-3687:
-------------------------------------

asaldhana~/jboss-4.0/testsuite>ant -Dtest=org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase one-test
Buildfile: build.xml

one-test:
   [delete] Deleting: C:\cygwin\home\asaldhana\jboss-4.0\testsuite\output\log\test.log
    [junit] Running org.jboss.test.security.test.CustomPrincipalPropagationUnitTestCase
    [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.672 sec

BUILD SUCCESSFUL
Total time: 5 seconds


Not able to reproduce through a personal testcase.

> Test case for Custom Principal Propagation
> ------------------------------------------
>
>                 Key: JBAS-3687
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3687
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> As indicated in the forum thread, there seems to be an issue with the propagation of caller principal (that is of type Custom Principal).  There is a claim that the principal that is propagated happens to be of type SimplePrincipal.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 11:42:06 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 22 Sep 2006 11:42:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBCACHE-777) FileCacheLoader
 can return
 null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14502461.1158939726071.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno reassigned JBCACHE-777:
----------------------------------------

    Assignee: Galder Zamarreno  (was: Manik Surtani)

> FileCacheLoader can return null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn)
> ------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) which goes against the JavaDoc 
> requirements for that method:
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If a get(fqn) operation occurrs before a put and the node (directory) does not exist, FCL returns 
> null when it should return an empty Map.
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 12:24:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 22 Sep 2006 12:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3687) Test case for Custom
 Principal Propagation
In-Reply-To: <29849048.1158936845481.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19265306.1158942241208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3687?page=all ]

Anil Saldhana closed JBAS-3687.
-------------------------------

    Resolution: Done

> Test case for Custom Principal Propagation
> ------------------------------------------
>
>                 Key: JBAS-3687
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3687
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> As indicated in the forum thread, there seems to be an issue with the propagation of caller principal (that is of type Custom Principal).  There is a claim that the principal that is propagated happens to be of type SimplePrincipal.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:00:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Fri, 22 Sep 2006 13:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-105) Make this JSF
 based system work on JBoss Portal 2.4
In-Reply-To: <7238225.1153926131402.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9133203.1158944401256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-105?page=all ]

Ryszard Kozmik resolved JBFORUMS-105.
-------------------------------------

    Resolution: Done

FINALLY DONE!

> Make this JSF based system work on JBoss Portal 2.4
> ---------------------------------------------------
>
>                 Key: JBFORUMS-105
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-105
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 1 week, 7 hours
>
> Investigate what need to be done to make this work on JBoss Portal 2.4
> Currently supported Portal version = 2.2.1RC1

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:06:01 2006
From: jira-events at jboss.com (Bill Burke (JIRA))
Date: Fri, 22 Sep 2006 13:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3684) References to
	TxManager
In-Reply-To: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23956163.1158944761297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3684?page=all ]

Bill Burke updated JBAS-3684:
-----------------------------

    Assignee: William DeCoste  (was: Bill Burke)

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3684
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.
>       ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
>       ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java
> These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:42:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1042) Add AJAX
	request Javascript
In-Reply-To: <13107312.1158456047454.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8998182.1158946921461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1042?page=all ]

Roy Russo resolved JBPORTAL-1042.
---------------------------------

    Resolution: Done

> Add AJAX request Javascript
> ---------------------------
>
>                 Key: JBPORTAL-1042
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1042
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Add DOM walker and storing of original values, and try to supply this to backend:
> - window id/window name
> - source coordinates (region / index)
> - destination coordinates (regin / index)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:42:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1011) Drag&drop
	documentation
In-Reply-To: <26617813.1156995824966.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26545044.1158946922289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1011?page=all ]

Roy Russo reassigned JBPORTAL-1011:
-----------------------------------

    Assignee: Roy Russo  (was: Tomasz Szymanski)

>  Drag&drop documentation
> ------------------------
>
>                 Key: JBPORTAL-1011
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1011
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Provide documentation for the drag&drop

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:42:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1009) Drag&drop unit
	tests
In-Reply-To: <30549920.1156995344268.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7054807.1158946922674.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1009?page=all ]

Roy Russo reassigned JBPORTAL-1009:
-----------------------------------

    Assignee: Roy Russo  (was: Tomasz Szymanski)

> Drag&drop unit tests
> --------------------
>
>                 Key: JBPORTAL-1009
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1009
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Per Julien:
> - the validation of JsUnit framework
> - it is integrated in the portal testsuite (using some variable to 
> control the browser tested)
> - it is integrated with cruisecontrol with a wide choice a browsers - QA

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:45:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1008) Integrate
 drap&drop theme into the Portal (no persistence)
In-Reply-To: <6025777.1156995224349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19199659.1158947101317.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1008?page=all ]

Roy Russo reassigned JBPORTAL-1008:
-----------------------------------

    Assignee: Roy Russo  (was: Tomasz Szymanski)

> Integrate drap&drop theme into the Portal (no persistence)
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1008
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1008
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Julien:
> the theme is integrated within the portal but the usage is made 
> optional until we find a way to control theme degradability to no 
> javascript. Roy and Julien will cooperate on that. For now we only 
> expect no persitence of changes until dashboard is implemented. So 
> changes are stored in http session.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:45:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1008) Integrate
 drap&drop theme into the Portal (no persistence)
In-Reply-To: <6025777.1156995224349.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <472239.1158947101461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1008?page=all ]

Roy Russo resolved JBPORTAL-1008.
---------------------------------

    Resolution: Done

> Integrate drap&drop theme into the Portal (no persistence)
> ----------------------------------------------------------
>
>                 Key: JBPORTAL-1008
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1008
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>            Reporter: Alex Pinkin
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Julien:
> the theme is integrated within the portal but the usage is made 
> optional until we find a way to control theme degradability to no 
> javascript. Roy and Julien will cooperate on that. For now we only 
> expect no persitence of changes until dashboard is implemented. So 
> changes are stored in http session.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:45:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Fri, 22 Sep 2006 13:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1056) Drag/Drop
 dropmarker for better user experience
Message-ID: <14908268.1158947101578.JavaMail.jira@cloud.prod.atl2.jboss.com>

Drag/Drop dropmarker for better user experience
-----------------------------------------------

                 Key: JBPORTAL-1056
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1056
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 13:53:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 22 Sep 2006 13:53:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3688) test component field
	required?
Message-ID: <11364463.1158947581013.JavaMail.jira@cloud.prod.atl2.jboss.com>

test component field required?
------------------------------

                 Key: JBAS-3688
                 URL: http://jira.jboss.com/jira/browse/JBAS-3688
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Ryan Campbell
         Assigned To: Ryan Campbell


test if the component field is required

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 14:02:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Fri, 22 Sep 2006 14:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-3688) test component field
	required?
Message-ID: <5220647.1158948121191.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3688?page=all ]

Ryan Campbell deleted JBAS-3688:
--------------------------------


> test component field required?
> ------------------------------
>
>                 Key: JBAS-3688
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3688
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Ryan Campbell
>         Assigned To: Ryan Campbell
>
> test if the component field is required

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 14:26:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 14:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <18170394.1158949561728.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis reassigned JBAS-3683:
----------------------------------------

    Assignee: Dimitris Andreadis

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 14:32:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 22 Sep 2006 14:32:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <29651206.1158949921282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis updated JBAS-3683:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.6.CR1)

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 15:20:01 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 22 Sep 2006 15:20:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1057) Create/update
 DTD/schemas for descriptors.
Message-ID: <11332006.1158952801489.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create/update DTD/schemas for descriptors.
------------------------------------------

                 Key: JBPORTAL-1057
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1057
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Documentation
    Affects Versions: 2.4 Final
            Reporter: Chris Laprun
         Assigned To: Roy Russo
            Priority: Minor
             Fix For: 2.4.1 Final




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 15:23:00 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Fri, 22 Sep 2006 15:23:00 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1058) Create
 DTD/Schema for WSRP deployment descriptors (-wsrp.xml)
Message-ID: <17592829.1158952980981.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create DTD/Schema for WSRP deployment descriptors (-wsrp.xml)
-------------------------------------------------------------

                 Key: JBPORTAL-1058
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1058
             Project: JBoss Portal
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Portal WSRP
    Affects Versions: 2.4 Final
            Reporter: Chris Laprun
         Assigned To: Chris Laprun
            Priority: Minor
             Fix For: 2.4.1 Final




-- 
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

        


From jira-events at jboss.com  Fri Sep 22 15:38:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 22 Sep 2006 15:38:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (EJBTHREE-523) implement jmx-name
	in jboss.xml
Message-ID: <11661404.1158953881212.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-523?page=all ]

William DeCoste closed EJBTHREE-523.
------------------------------------

    Fix Version/s: EJB 3.0 RC10 - FD
       Resolution: Done

> implement jmx-name in jboss.xml
> -------------------------------
>
>                 Key: EJBTHREE-523
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-523
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC6 - PFD
>            Reporter: William DeCoste
>         Assigned To: William DeCoste
>            Priority: Minor
>             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

        


From jira-events at jboss.com  Fri Sep 22 16:02:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Fri, 22 Sep 2006 16:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-146) purge rule for ant
 in trailblazer does not remove class files.
Message-ID: <1870121.1158955321220.JavaMail.jira@cloud.prod.atl2.jboss.com>

purge rule for ant in trailblazer does not remove class files.
--------------------------------------------------------------

                 Key: JBESB-146
                 URL: http://jira.jboss.com/jira/browse/JBESB-146
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Examples
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
            Priority: Minor
             Fix For: 4.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

        


From jira-events at jboss.com  Fri Sep 22 16:11:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Fri, 22 Sep 2006 16:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3689) Naming fails to
 accept a custom client socket
Message-ID: <31568337.1158955861048.JavaMail.jira@cloud.prod.atl2.jboss.com>

Naming fails to accept a custom client socket
---------------------------------------------

                 Key: JBAS-3689
                 URL: http://jira.jboss.com/jira/browse/JBAS-3689
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.3 SP1
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


Attempting to set a custom client socket on the NamingService
   <mbean code="org.jboss.naming.NamingService"
      name="jboss:service=Naming"
      xmbean-dd="resource:xmdesc/NamingService-xmbean.xml">
      <!-- The call by value mode. true if all lookups are unmarshalled using
      the caller's TCL, false if in VM lookups return the value by reference.
      -->
      <attribute name="CallByValue">false</attribute>
      <!-- The listening port for the bootstrap JNP service. Set this to -1
        to run the NamingService without the JNP invoker listening port.
      -->
      <attribute name="Port">1099</attribute>
      <attribute name="RmiPort">1098</attribute>
      <!-- The bootstrap JNP server bind address. This also sets the default
      RMI service bind address. Empty == all addresses
       -->
      <attribute name="BindAddress">${iface.A}</attribute>
      <attribute name="RmiBindAddress">${iface.A}</attribute>
      <!-- The thread pool service used to control the bootstrap lookups -->
      <depends optional-attribute-name="LookupPool"
         proxy-type="attribute">jboss.system:service=ThreadPool</depends>
      <attribute name="ClientSocketFactory">case9179.TimeoutClientSocketFactory</attribute>
   </mbean>

fails with:

2006-09-22 12:46:12,417 WARN  [org.jboss.naming.NamingService] Failed to setBindAddress=/192.168.2.107 on socket factory
java.lang.NullPointerException: case9179.TimeoutClientSocketFactory.setBindAddress invoked on null object
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at java.lang.reflect.Method.invoke(Ljava.lang.Object;[Ljava.lang.Object;J)Ljava.lang.Object;(Unknown Source)
	at org.jnp.server.Main.initCustomSocketFactories(Main.java:355)
	at org.jnp.server.Main.start(Main.java:255)
	at org.jboss.naming.NamingService.startService(NamingService.java:221)

The problem is that there copy/paste error at line 355:

   protected void initCustomSocketFactories()
   {
      // Use either the rmiBindAddress or bindAddress for the RMI service
      InetAddress addr = rmiBindAddress;
      if( addr == null )
         addr = bindAddress;

      if( clientSocketFactory != null )
      {
         // See if the client socket supports setBindAddress(String)
         try
         {
            Class csfClass = clientSocketFactory.getClass();
            Class[] parameterTypes = {String.class};
            Method m = csfClass.getMethod("setBindAddress", parameterTypes);
            Object[] args = {addr.getHostAddress()};
            m.invoke(serverSocketFactory, args); // +++ line 355, This should be clientSocketFactory
         }
         catch (NoSuchMethodException e)
         {
            log.warn("Socket factory does not support setBindAddress(String)");
            // Go with default address
         }


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 18:20:02 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 18:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-526) JMSRedelivered
 flag not correctly set on true in certain redelivery scenarios
In-Reply-To: <7518420.1156267151480.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3408288.1158963602089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-526?page=all ]

Ovidiu Feodorov closed JBMESSAGING-526.
---------------------------------------

    Resolution: Done

> JMSRedelivered flag not correctly set on true in certain redelivery scenarios
> -----------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-526
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-526
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.0.1.CR5, 1.2.0.Alpha1
>
>
> Added TransactedSessionTest.testRedeliveredQueue2() that currently fails.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 18:20:02 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 18:20:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <33261906.1158963602658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 19:08:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 22 Sep 2006 19:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3684) References to
	TxManager
In-Reply-To: <1604239.1158899401273.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6358785.1158966481294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3684?page=all ]

William DeCoste closed JBAS-3684.
---------------------------------

    Resolution: Done

> References to TxManager
> -----------------------
>
>                 Key: JBAS-3684
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3684
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Kevin Conner
>         Assigned To: William DeCoste
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> The following classes contain direct references to org.jboss.tm.TxManager.  These references prevent JBossTS being used as a replacement for TxManager.
>       ejb3/src/main/org/jboss/ejb3/tx/TxInterceptorFactory.java
>       ejb3/src/main/org/jboss/ejb3/entity/ManagedEntityManagerFactory.java
> These should be changed to defer to TxUtil or to use TransactionManagerLocator.getInstance().locate().

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 19:39:01 2006
From: jira-events at jboss.com (William DeCoste (JIRA))
Date: Fri, 22 Sep 2006 19:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-715) complete
 implementation of interceptor-order in ejb-jar.xml
Message-ID: <16762800.1158968341039.JavaMail.jira@cloud.prod.atl2.jboss.com>

complete implementation of interceptor-order in ejb-jar.xml
-----------------------------------------------------------

                 Key: EJBTHREE-715
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-715
             Project: EJB 3.0
          Issue Type: Task
            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

        


From jira-events at jboss.com  Fri Sep 22 22:08:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-550) Add JBoss
 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
In-Reply-To: <5205854.1158809458341.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14399176.1158977281311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-550?page=all ]

Ovidiu Feodorov updated JBMESSAGING-550:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> Add JBoss 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-550
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-550
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:08:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-550) Add JBoss
 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
In-Reply-To: <5205854.1158809458341.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17569573.1158977281615.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-550?page=all ]

Ovidiu Feodorov closed JBMESSAGING-550.
---------------------------------------

    Resolution: Done

> Add JBoss 4.0.5.CR1 (expanded and installer-generated) to the smoke test suite
> ------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-550
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-550
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:11:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <27280870.1158977461118.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov updated JBMESSAGING-302:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:11:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 22 Sep 2006 22:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-302) Invoking Topic
 management
 interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with
 empty params throws exception
Message-ID: <12688862.1158977461253.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-302?page=all ]

Ovidiu Feodorov closed JBMESSAGING-302.
---------------------------------------

    Resolution: Done

> Invoking Topic management interface's listMessagesDurableSub()/ listMessagesNonDurableSub() with empty params throws exception
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-302
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-302
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> 9:18:53,568 ERROR [[HtmlAdaptor]] Servlet.service() for servlet HtmlAdaptor threw exception
> ava.lang.NumberFormatException: For input string: ""
>        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
>        at java.lang.Long.parseLong(Long.java:424)
>        at java.lang.Long.valueOf(Long.java:518)
>        at sun.beans.editors.LongEditor.setAsText(LongEditor.java:24)
>        at org.jboss.util.propertyeditor.PropertyEditors.convertValue(PropertyEditors.java:260)
>        at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:239)
>        at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:223)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:262)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:100)
>        at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:82)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
>        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>        at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:54)
>        at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:173)
>        at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
>        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
>        at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
>        at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>        at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>        at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Fri Sep 22 22:29:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Fri, 22 Sep 2006 22:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3339)
 ValidConnectionChecker for Sybase DB
Message-ID: <26492737.1158978541097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3339?page=all ]

Weston Price resolved JBAS-3339.
--------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                       (was: JBossAS-4.0.5.GA)
       Resolution: Done

Added SybaseValidConnection checker using equivalent select from dual method

> ValidConnectionChecker for Sybase DB
> ------------------------------------
>
>                 Key: JBAS-3339
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3339
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Weston Price
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta
>
>
> During consulting engagement a feature request for a Sybase validation connection checker was introduced. This would answer an issue for the client where RDBMS systems are brought down for mainteniance and they have to reboot JBossAS instances using Sybase. 

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 00:09:59 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Sat, 23 Sep 2006 00:09:59 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-2737)
 InternalManagedConnectionPool.removeTimedOut() should not destroy
 connections below the minimum pool size
Message-ID: <19138516.1158984599756.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2737?page=all ]

Weston Price resolved JBAS-2737.
--------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Added capability to force pool to never destroy connections below min if configured to do so.

> InternalManagedConnectionPool.removeTimedOut() should not destroy connections below the minimum pool size
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2737
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2737
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: SUSE Linux, Sun JDK 1.4.2_08 (though this issue would be relevant to all platforms)
>            Reporter: Jim Paterson
>             Fix For: JBossAS-5.0.0.Beta
>
>
> By default JBoss JDBC connection pools have a 15 minute idle time. Every time the IdleRemover runs it currently destroys every connection in the pool that has not been used in the last 15 minutes. It then establishes new connections if necessary to take the pool back up to its minimum size.
> In most cases this behaviour probably doesn't cause problems. However, in our scenario it does. We are using DB2 and, in some situations, DB2 caches previously compiled query plans on a per connection basis. One specific example we have is a highly optimized search stored procedure that uses temporary tables. The IdleRemover is causing roughly 60% of our calls to this procedure to go through a new connection. This changes the response time from this stored procedure from ~200ms to ~2seconds as if triggers re-compilations in the database. 
> Because of this behaviour we do not want the application server to drop and restore connections unless they are in error or the pool has grown beyond the minimum size during a period of peak load. 
> I can understand that the current implementation protects the application server against stale connections. However, there are other mechanisms in the JDBC connection pool to handle this i.e. the the check-valid-connection-sql and valid-connection-checker-class-name parameters.
> Do you agree that the current implementation should be changed?

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:42:01 2006
From: jira-events at jboss.com (Scott Reed (JIRA))
Date: Sat, 23 Sep 2006 07:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-380) Create some
 decision table examples
In-Reply-To: <10327077.1153833972040.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24754101.1159011721420.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-380?page=comments#action_12343874 ] 
            
Scott Reed commented on JBRULES-380:
------------------------------------

One example for each example in the DRL rule docs would have helped me a lot. 

> Create some decision table examples
> -----------------------------------
>
>                 Key: JBRULES-380
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-380
>             Project: JBoss Rules
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables, Documentation
>    Affects Versions: 3.0
>            Reporter: lyle hayhurst
>         Assigned To: Mark Proctor
>         Attachments: barbarian.xls, dtex.tar.gz, test.rar
>
>   Original Estimate: 1 day
>          Time Spent: 3 hours
>  Remaining Estimate: 1 day
>
> As per IRC, some more fleshed out examples of decision tables in action.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:45:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 23 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-778) Refactor package
	distribution
Message-ID: <31189905.1159011901144.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor package distribution
-----------------------------

                 Key: JBCACHE-778
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-778
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


Per disucssion, we are refactoring the distribution package for release 2.0.

1. jboss-cache-core-dist.zip. Core edition that contains the tradition cache library.
  - Only Cache (jboss-cache.jar) and supporting library
  - Ref doc
  - faq
  - tutorial

2. jboss-cache-pojo-dist.zip. PojoCache edition. It has jboss-cache-core-dist.zip, plus
  - pojocache.jar that contains the PojoCache lib
  - additional JBoss Aop, trove, javassist, jboss-aop-jdk50.jar, qdox.jar
  - PojoCache ref doc
  - faq-pojo for PojoCache
 
3. jboss-cache-all-dist.zip. Everything PojoCache has, plus
 - javadoc
 - src


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:45:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 23 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-779) Split the faq
 directory into faq and faq-pojo
Message-ID: <16060951.1159011901263.JavaMail.jira@cloud.prod.atl2.jboss.com>

Split the faq directory into faq and faq-pojo
---------------------------------------------

                 Key: JBCACHE-779
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-779
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: 2.0.0


faq is for core JBoss Cache while faq-pojo is for PojoCache

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:45:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sat, 23 Sep 2006 07:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-779) Split the faq
 directory into faq and faq-pojo
In-Reply-To: <16060951.1159011901263.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32202487.1159011901381.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-779?page=all ]

Ben Wang resolved JBCACHE-779.
------------------------------

    Resolution: Done

> Split the faq directory into faq and faq-pojo
> ---------------------------------------------
>
>                 Key: JBCACHE-779
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-779
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> faq is for core JBoss Cache while faq-pojo is for PojoCache

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 07:51:01 2006
From: jira-events at jboss.com (Scott Reed (JIRA))
Date: Sat, 23 Sep 2006 07:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-501) DRL -> decision
 table (round trip)
Message-ID: <7645154.1159012261138.JavaMail.jira@cloud.prod.atl2.jboss.com>

DRL -> decision table (round trip)
----------------------------------

                 Key: JBRULES-501
                 URL: http://jira.jboss.com/jira/browse/JBRULES-501
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Scott Reed
         Assigned To: Mark Proctor


It would be extremely useful to be able to convert existing rules to decision tables. The educational value alone would make it worth while, but it would speed up development as well since the DRL -> decision table mapping is not straight forward and cell merging and coloring is fairly tedious. 

Users would probably want to be able to select the rules and functions to be mapped. If so, then the results of the mapping would have to be one or more decision table files and a new DRL file containing the rules and functions that were not converted.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:33:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-338) Changes to
 SeamInterceptor break non-JSF calls.
In-Reply-To: <8417461.1156344946502.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18089338.1159014781294.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-338?page=all ]

Gavin King closed JBSEAM-338.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done

fixed, but not properly tested

> Changes to SeamInterceptor break non-JSF calls.
> -----------------------------------------------
>
>                 Key: JBSEAM-338
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-338
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> The CVS changes to SeamInterceptor have it call Component.forName() outside of the Seam contexts when called via MDB or RMI. Need to call beginCall(), endCall() from the @PostConstruct and @PostActivate methods.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:33:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-358) Adding
 core.FacesMessages requires JSF libraries to compile component
In-Reply-To: <21739116.1158918901085.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5633910.1159014781450.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-358?page=comments#action_12343876 ] 
            
Gavin King commented on JBSEAM-358:
-----------------------------------

No, this is not the reason for it. FacesMessages is totally dependent to JSF for its functionality and even its API.

> Adding core.FacesMessages requires JSF libraries to compile component
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-358
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-358
>             Project: JBoss Seam
>          Issue Type: Bug
>            Reporter: Christian Bauer
>            Priority: Minor
>
> I have this in a Seam component:
>     // For error messages
>     @In(create=true)
>     private FacesMessages facesMessages;
> This is org.jboss.seam.core.FacesMessages. It doesn't extend anything from JSF but I still can't compile my Seam component without the JSF stubs on the classpath:
> /Users/turin/work/local/lab8/modules/beans/src/auction/beans/PlaceBidImpl.java
>     Error:Error:line (112)cannot access javax.faces.application.FacesMessage
> file javax/faces/application/FacesMessage.class not found
> This is inconvenient because this is the only JSF compile-time dependency in all of my Seam components and I have to add the JSF libs to my compile classpath just for this. I don't really know why this is required... because of the static methods in FacesMessages?
> In any case, it would be nice to be able to send JSF messages without binding the component to JSF and I initially thought that this was the usecase for core.FacesMessages in Seam.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:36:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-358) Adding
 core.FacesMessages requires JSF libraries to compile component
In-Reply-To: <21739116.1158918901085.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1759034.1159014961169.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-358?page=all ]

Gavin King closed JBSEAM-358.
-----------------------------

    Resolution: Won't Fix

> Adding core.FacesMessages requires JSF libraries to compile component
> ---------------------------------------------------------------------
>
>                 Key: JBSEAM-358
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-358
>             Project: JBoss Seam
>          Issue Type: Bug
>            Reporter: Christian Bauer
>            Priority: Minor
>
> I have this in a Seam component:
>     // For error messages
>     @In(create=true)
>     private FacesMessages facesMessages;
> This is org.jboss.seam.core.FacesMessages. It doesn't extend anything from JSF but I still can't compile my Seam component without the JSF stubs on the classpath:
> /Users/turin/work/local/lab8/modules/beans/src/auction/beans/PlaceBidImpl.java
>     Error:Error:line (112)cannot access javax.faces.application.FacesMessage
> file javax/faces/application/FacesMessage.class not found
> This is inconvenient because this is the only JSF compile-time dependency in all of my Seam components and I have to add the JSF libs to my compile classpath just for this. I don't really know why this is required... because of the static methods in FacesMessages?
> In any case, it would be nice to be able to send JSF messages without binding the component to JSF and I initially thought that this was the usecase for core.FacesMessages in Seam.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 08:39:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 08:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-359) Abstract Seam core
 components from JSF-EL
Message-ID: <15279714.1159015141124.JavaMail.jira@cloud.prod.atl2.jboss.com>

Abstract Seam core components from JSF-EL
-----------------------------------------

                 Key: JBSEAM-359
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-359
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King


Currently a bunch of core components (and possibly other stuff) calls to JSF for EL evaluation. We have already said we will migrate to using the unified EL stuff. However, the user should be able to plug in their own EL (eg. OGNL), so we should introduce a new core component ExpressionEvaluator to allow custom creation of MethodBindings and ValueBindings.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 09:00:01 2006
From: jira-events at jboss.com (Scott Reed (JIRA))
Date: Sat, 23 Sep 2006 09:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-502) Add binding
 semantics for decision table authors
Message-ID: <3845829.1159016401254.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add binding semantics for decision table authors
------------------------------------------------

                 Key: JBRULES-502
                 URL: http://jira.jboss.com/jira/browse/JBRULES-502
             Project: JBoss Rules
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Decision tables
            Reporter: Scott Reed
         Assigned To: Mark Proctor


The expressive capability of decision tables for non-programmer authors is limited.  Especially, the author has no way to tell the developer to use the value of a property from one column in the condition for another. I can think of two ways that binding semantics could be added:
  Use the comment cells (i.e. "Age: Person's Age") - this is simple and expressive but would cause problems if an author wants to use the '<word>:' construct in a comment without intending it to be a binding.
  Add a designated row above or below the comment row.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 10:06:01 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Sat, 23 Sep 2006 10:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-501) DRL -> decision
 table (round trip)
In-Reply-To: <7645154.1159012261138.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25391831.1159020361364.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-501?page=comments#action_12343877 ] 
            
Mark Proctor commented on JBRULES-501:
--------------------------------------

its a nice idea, but I don't see how this  would work - as many rules do not map well to decision tables.  Still you can try this  one yourself. You can take a Package and then use the xml/drl dumper as examples on how to dump to a different format.

> DRL -> decision table (round trip)
> ----------------------------------
>
>                 Key: JBRULES-501
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-501
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Decision tables
>            Reporter: Scott Reed
>         Assigned To: Mark Proctor
>
> It would be extremely useful to be able to convert existing rules to decision tables. The educational value alone would make it worth while, but it would speed up development as well since the DRL -> decision table mapping is not straight forward and cell merging and coloring is fairly tedious. 
> Users would probably want to be able to select the rules and functions to be mapped. If so, then the results of the mapping would have to be one or more decision table files and a new DRL file containing the rules and functions that were not converted.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 10:15:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 23 Sep 2006 10:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3641) Updated
 bin/jboss_init_hpux.sh script
Message-ID: <32003728.1159020901152.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3641?page=all ]

Dimitris Andreadis closed JBAS-3641.
------------------------------------

    Resolution: Done

Updated.

> Updated bin/jboss_init_hpux.sh script
> -------------------------------------
>
>                 Key: JBAS-3641
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3641
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>         Environment: HP-UX
>            Reporter: john mendonca
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>         Attachments: jboss_init_hpux.sh, jboss_init_hpux.sh
>
>
> Entered at the request of Luc Texier:
> <HP request from the Customer support Portal>
> Please replace the <jbosshome>/bin/jboss_init_hpux.sh script with the attached updated version in your next release cycle:
> - handles multiple jboss as instances
> - updated comments (including installation instructions)
> - more robust code

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 10:39:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 23 Sep 2006 10:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <25291334.1159022341335.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3683?page=comments#action_12343879 ] 
            
Dimitris Andreadis commented on JBAS-3683:
------------------------------------------

Thanks! Why you changed some counters to Gauge32 and left 2 of them as INTEGER?

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:51:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-355) Constructor
 injection of component dependencies
In-Reply-To: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24926422.1159026661061.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-355?page=comments#action_12343880 ] 
            
Gavin King commented on JBSEAM-355:
-----------------------------------

The reason I don't support constructor injection is that I can't do constructor injection for session beans 'cos EJB3 doesn't support it (there is a reason for this, btw).


> Constructor injection of component dependencies
> -----------------------------------------------
>
>                 Key: JBSEAM-355
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Minor
>
> Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 
> Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.
> Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:54:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-47) Entity beans and
 session replication
Message-ID: <11095584.1159026841315.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-47?page=comments#action_12343881 ] 
            
Gavin King commented on JBSEAM-47:
----------------------------------

This can now be handled my @Mutable .... should we make @Mutable a default for @Entity?

> Entity beans and session replication
> ------------------------------------
>
>                 Key: JBSEAM-47
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-47
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>
> We need to force HttpSession puts for entity bean and java bean components to ensure that state changes get replicated...

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:54:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-47) Entity beans and
 session replication
Message-ID: <17575421.1159026841507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-47?page=all ]

Gavin King updated JBSEAM-47:
-----------------------------

    Priority: Minor  (was: Major)

Downgrading, 'cos it is now just a question of sensible defaulting.

> Entity beans and session replication
> ------------------------------------
>
>                 Key: JBSEAM-47
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-47
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Minor
>
> We need to force HttpSession puts for entity bean and java bean components to ensure that state changes get replicated...

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:57:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-351) method instance() in
 userPrincipal should be static
In-Reply-To: <29304742.1158151114106.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23119061.1159027021364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-351?page=all ]

Gavin King closed JBSEAM-351.
-----------------------------

    Fix Version/s: 1.1
       Resolution: Done
         Assignee: Gavin King

thanks, fixed

> method instance() in userPrincipal should be static
> ---------------------------------------------------
>
>                 Key: JBSEAM-351
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-351
>             Project: JBoss Seam
>          Issue Type: Patch
>          Components: Core
>    Affects Versions: 1.1
>            Reporter: Michael Steiner
>         Assigned To: Gavin King
>            Priority: Trivial
>             Fix For: 1.1
>
>         Attachments: patch.txt
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 11:57:03 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 11:57:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-332) javabeans in
 session are not distributable
In-Reply-To: <13441536.1155654861191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12650451.1159027023664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-332?page=all ]

Gavin King updated JBSEAM-332:
------------------------------

    Priority: Critical  (was: Major)

upgrading

> javabeans in session are not distributable
> ------------------------------------------
>
>                 Key: JBSEAM-332
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-332
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0, JBoss 4.0.4GA, Windows Server 2003, Cluster of 4 nodes on 2 machines.
>            Reporter: Keith Naas
>         Assigned To: Gavin King
>            Priority: Critical
>         Attachments: itpa.ear, itpa.ear
>
>
> We have an application that makes use of JavaBeans for a lot of our JSF "actions".  When one of our nodes is brought down, the session should Seamlessly failover to another node.  The user is sent  to a different node, but the entire session appears to be in a clean state.   We looked through the server logs and saw the following:
> 2006-08-15 10:47:36,658 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheService] [.......] loadSession(): id: GWrcdSJEASvXSJnX6fNHNg**exception occurred during serialization: java.lang.ClassNotFoundException: No ClassLoaders found for: com.ourapp.web.beans.WorksheetBean$$EnhancerByCGLIB$$bf40374c
> All of our beans are Serializable, but it appears that there is an issue with the cache sync of the CGLib proxy classes.  This specific bean does have some service properties that are transients.  It also has properties that refer to other Web JavaBeans.  
> We will be investigating this some more, but we wanted to get this logged since it appears to be a major issue that prevents us from clustering our Seam apps.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-360) Seam managed
 persistence contexts and clusters
Message-ID: <1571973.1159027381169.JavaMail.jira@cloud.prod.atl2.jboss.com>

Seam managed persistence contexts and clusters
----------------------------------------------

                 Key: JBSEAM-360
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-360
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
            Priority: Critical
             Fix For: 1.1


I have designed a new mechanism which allows:

(1) efficiencies when using replicated EPCs
(2) fix for a bug when using a Seam-managed EPC in a cluster

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-360) Seam managed
 persistence contexts and clusters
In-Reply-To: <1571973.1159027381169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6241306.1159027381285.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-360?page=all ]

Gavin King closed JBSEAM-360.
-----------------------------

    Resolution: Done

> Seam managed persistence contexts and clusters
> ----------------------------------------------
>
>                 Key: JBSEAM-360
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-360
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> I have designed a new mechanism which allows:
> (1) efficiencies when using replicated EPCs
> (2) fix for a bug when using a Seam-managed EPC in a cluster

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-361) Support
 @PrePassivate, 
 @PostActivate, @PostConstruct for JavaBean components and interceptors
Message-ID: <12292647.1159027381423.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support @PrePassivate, @PostActivate, @PostConstruct for JavaBean components and interceptors
---------------------------------------------------------------------------------------------

                 Key: JBSEAM-361
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-361
             Project: JBoss Seam
          Issue Type: Feature Request
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Support a richer lifecycle in both Seam interceptors and Seam JavaBean components.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:03:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-361) Support
 @PrePassivate, 
 @PostActivate, @PostConstruct for JavaBean components and interceptors
In-Reply-To: <12292647.1159027381423.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23526124.1159027381562.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-361?page=all ]

Gavin King closed JBSEAM-361.
-----------------------------

    Resolution: Done

> Support @PrePassivate, @PostActivate, @PostConstruct for JavaBean components and interceptors
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-361
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-361
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Support a richer lifecycle in both Seam interceptors and Seam JavaBean components.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:09:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-362) Improvements to
	compnents.xml
Message-ID: <5637850.1159027741125.JavaMail.jira@cloud.prod.atl2.jboss.com>

Improvements to compnents.xml
-----------------------------

                 Key: JBSEAM-362
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-362
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


The following improvements:

(1) Let scope be specified
(2) allow components to be wired via EL
(3) allow multi-valued properties to be initialized
(4) create an alias for another component

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:09:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-362) Improvements to
	compnents.xml
In-Reply-To: <5637850.1159027741125.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5289355.1159027741296.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-362?page=all ]

Gavin King closed JBSEAM-362.
-----------------------------

    Resolution: Done

> Improvements to compnents.xml
> -----------------------------
>
>                 Key: JBSEAM-362
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-362
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> The following improvements:
> (1) Let scope be specified
> (2) allow components to be wired via EL
> (3) allow multi-valued properties to be initialized
> (4) create an alias for another component

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:11:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-363) Make pageflow
 component into a user visible API
Message-ID: <7913515.1159027861071.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make pageflow component into a user visible API
-----------------------------------------------

                 Key: JBSEAM-363
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-363
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1




-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:11:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-363) Make pageflow
 component into a user visible API
In-Reply-To: <7913515.1159027861071.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6957688.1159027861177.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-363?page=all ]

Gavin King closed JBSEAM-363.
-----------------------------

    Resolution: Done

> Make pageflow component into a user visible API
> -----------------------------------------------
>
>                 Key: JBSEAM-363
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-363
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:13:04 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:13:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-132) Annotation for
 redirect on exception
Message-ID: <6313231.1159027984137.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-132?page=comments#action_12343885 ] 
            
Gavin King commented on JBSEAM-132:
-----------------------------------

Note this encompasses @Render, @HttpError and @Redirect

> Annotation for redirect on exception
> ------------------------------------
>
>                 Key: JBSEAM-132
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-132
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Arash Bijanzadeh
>         Assigned To: Gavin King
>            Priority: Optional
>             Fix For: 1.1
>
>
> It would be very nice if you could add an anotation to seam which redirects a specific type of exception to a specific outcome. 

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:16:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-320) client-side
	interceptors
In-Reply-To: <33405608.1153952051370.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9390257.1159028161310.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-320?page=comments#action_12343886 ] 
            
Gavin King commented on JBSEAM-320:
-----------------------------------

Note this also involved replacing @Within and @Around with @Interceptor

> client-side interceptors
> ------------------------
>
>                 Key: JBSEAM-320
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-320
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:34:01 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Sat, 23 Sep 2006 12:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-364) Use reflection in
 org.jboss.seam.util.Persistence
Message-ID: <20736586.1159029241179.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use reflection in org.jboss.seam.util.Persistence
-------------------------------------------------

                 Key: JBSEAM-364
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-364
             Project: JBoss Seam
          Issue Type: Bug
          Components: Core
            Reporter: Gavin King
            Priority: Critical


Currently we got a hard dependence to Hibernate. We should use reflection in this class.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 12:40:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Sat, 23 Sep 2006 12:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-355) Constructor
 injection of component dependencies
In-Reply-To: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11490381.1159029601189.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-355?page=comments#action_12343887 ] 
            
Christian Bauer commented on JBSEAM-355:
----------------------------------------

OK, but why not offer it for entities?


> Constructor injection of component dependencies
> -----------------------------------------------
>
>                 Key: JBSEAM-355
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Minor
>
> Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 
> Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.
> Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.

-- 
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

        


From wealthy888 at yahoo.com  Sun Sep 24 00:15:33 2006
From: wealthy888 at yahoo.com (¨ÕÃ³Õ)
Date: Sun, 24 Sep 2006 00:15:33
Subject: [jboss-jira] =?iso-8859-1?q?=E0=BB=C5=D5=E8=C2=B9=E0=C7=C5=D2=CB?=
	=?iso-8859-1?q?=C5=D1=A7=E0=C5=D4=A1=A7=D2=B9=E0=BB=E7=B9=E0=A7=D4?=
	=?iso-8859-1?q?=B9=24=24=24?=
Message-ID: <200609231715.k8NHFXfL026316@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060924/3f168ba4/attachment-0001.html 

From jira-events at jboss.com  Sat Sep 23 14:28:01 2006
From: jira-events at jboss.com (John Gilbert (JIRA))
Date: Sat, 23 Sep 2006 14:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-147) Document Design
 Notes on Interaction Differences in the New Architecture
Message-ID: <19387768.1159036081405.JavaMail.jira@cloud.prod.atl2.jboss.com>

Document Design Notes on Interaction Differences in the New Architecture
------------------------------------------------------------------------

                 Key: JBESB-147
                 URL: http://jira.jboss.com/jira/browse/JBESB-147
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0
            Reporter: John Gilbert
         Assigned To: Mark Little
            Priority: Minor


Wiki Page: http://wiki.jboss.org/wiki/Wiki.jsp?page=InteractionDifferencesInTheNewArchitecture

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 14:49:05 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 14:49:05 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-28) Possibility to
 choose Forums first view.
Message-ID: <21354811.1159037345538.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-28?page=comments#action_12343888 ] 
            
Ryszard Kozmik commented on JBFORUMS-28:
----------------------------------------

It is possible in new Forums.
If you want to have summary view as the default setting for every user the only thing you have to change is one of values of managed bean called "defaultPreferences" found in forums-config.xml.
Setting value of property "summarytopiclimit" to 0 will turn off summary view. Nevertheless each user can override this value in his preferences value. So, if he want summary view he can have one just for himself.

> Possibility to choose Forums first view.
> ----------------------------------------
>
>                 Key: JBFORUMS-28
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-28
>             Project: JBoss Forums
>          Issue Type: Feature Request
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 30 minutes
>
> It would be good to have possibility to choose between "Latest posted topics" view and normal forums' categories view as the first JBForums normal view.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 14:49:06 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 14:49:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-28) Possibility to
 choose Forums first view.
Message-ID: <27712240.1159037346138.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-28?page=all ]

Ryszard Kozmik resolved JBFORUMS-28.
------------------------------------

    Resolution: Done

> Possibility to choose Forums first view.
> ----------------------------------------
>
>                 Key: JBFORUMS-28
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-28
>             Project: JBoss Forums
>          Issue Type: Feature Request
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 30 minutes
>
> It would be good to have possibility to choose between "Latest posted topics" view and normal forums' categories view as the first JBForums normal view.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 14:58:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 14:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-123) On preview topic
 view "Powered by JBoss Portal" tag flies around
Message-ID: <4351983.1159037881234.JavaMail.jira@cloud.prod.atl2.jboss.com>

On preview topic view "Powered by JBoss Portal" tag flies around
----------------------------------------------------------------

                 Key: JBFORUMS-123
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-123
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.0.0 Alpha
            Reporter: Ryszard Kozmik
         Assigned To: Ryszard Kozmik
            Priority: Minor


While creating topic with preview the theme tag "Powered by JBoss Portal / Theme by ***" flies over forums.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 15:01:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 15:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-124) Repair links to
 communicators, private message and e-mail
Message-ID: <30912966.1159038061046.JavaMail.jira@cloud.prod.atl2.jboss.com>

Repair links to communicators, private message and e-mail
---------------------------------------------------------

                 Key: JBFORUMS-124
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-124
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.0.0 Alpha
            Reporter: Ryszard Kozmik
         Assigned To: Ryszard Kozmik
            Priority: Minor


After adding all information for user about his/her communicators, e-mail etc. TopicView and UserView is showing exceptions connected with generating wrong URL structure for communicators/e-mail buttons.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 15:04:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 15:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-125) BBCode URL Tag
	improvement
Message-ID: <3889348.1159038241186.JavaMail.jira@cloud.prod.atl2.jboss.com>

BBCode URL Tag improvement
--------------------------

                 Key: JBFORUMS-125
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-125
             Project: JBoss Forums
          Issue Type: Feature Request
          Components: Forum Enhancements
            Reporter: Ryszard Kozmik
             Fix For: 1.1.0 Alpha


BBCode's URL tag could work similar to html "a href" style like : [url=http://www.example.com]My Example[/url]

-- 
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

        


From c13 at fullmailmarket.com  Sat Sep 23 15:56:09 2006
From: c13 at fullmailmarket.com (ADSL Pyme!)
Date: Sat, 23 Sep 2006 15:56:09 -0400
Subject: [jboss-jira] ADSL Pyme-Empresas
Message-ID: <200609231956.k8NJu9YU030380@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060923/4ca00c73/attachment-0001.html 

From jira-events at jboss.com  Sat Sep 23 16:13:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 16:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-126) NewTopic on
 ForumsView doesn't work on IE
Message-ID: <7318128.1159042381055.JavaMail.jira@cloud.prod.atl2.jboss.com>

NewTopic on ForumsView doesn't work on IE
-----------------------------------------

                 Key: JBFORUMS-126
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-126
             Project: JBoss Forums
          Issue Type: Bug
    Affects Versions: 1.0.0 Alpha
            Reporter: Ryszard Kozmik
         Assigned To: Ryszard Kozmik
            Priority: Minor


Creating topic by NewTopic button on ForumsView is not possible when browsing Forums using IE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 16:55:01 2006
From: jira-events at jboss.com (Luca Stancapiano (JIRA))
Date: Sat, 23 Sep 2006 16:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
Message-ID: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>

testsuite on web about single sign on wrong (I think...)
--------------------------------------------------------

                 Key: JBAS-3690
                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.0.4.GA
         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
            Reporter: Luca Stancapiano


on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 17:07:01 2006
From: jira-events at jboss.com (Gerald Turner (JIRA))
Date: Sat, 23 Sep 2006 17:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <24200965.1159045621286.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3683?page=comments#action_12343889 ] 
            
Gerald Turner commented on JBAS-3683:
-------------------------------------

Dimitris, the reason that I changed some types to Gauge32 is because NET-SNMP complains about the type returned by the SNMP Agent not matching the MIB -  though I don't recall if these were merely warnings versus failure like the other syntax errors.  The reason I left some as INTEGER is because snmp-adaptor / RequestHandlerImpl converts Long attributes to SnmpUInt32 (Gauge32), and Integer attributes to SnmpInt32 (INTEGER), for example jboss.system:type=ServerInfo ActiveThreadCount is an Integer, thus it matced the MIB.

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 17:58:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 17:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-124) Repair links to
 communicators, private message and e-mail
In-Reply-To: <30912966.1159038061046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26710825.1159048681240.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-124?page=all ]

Ryszard Kozmik updated JBFORUMS-124:
------------------------------------

    Fix Version/s: 1.0.0 Alpha

Forgot to set Fix Version

> Repair links to communicators, private message and e-mail
> ---------------------------------------------------------
>
>                 Key: JBFORUMS-124
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-124
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>
> After adding all information for user about his/her communicators, e-mail etc. TopicView and UserView is showing exceptions connected with generating wrong URL structure for communicators/e-mail buttons.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 18:01:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 18:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-126) NewTopic on
 ForumsView doesn't work on IE
In-Reply-To: <7318128.1159042381055.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14730525.1159048861113.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-126?page=all ]

Ryszard Kozmik updated JBFORUMS-126:
------------------------------------

    Fix Version/s: 1.0.0 Alpha

Forgot to set Fix Version

> NewTopic on ForumsView doesn't work on IE
> -----------------------------------------
>
>                 Key: JBFORUMS-126
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-126
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>
> Creating topic by NewTopic button on ForumsView is not possible when browsing Forums using IE.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 18:01:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 18:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-123) On preview topic
 view "Powered by JBoss Portal" tag flies around
In-Reply-To: <4351983.1159037881234.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2498831.1159048861232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-123?page=all ]

Ryszard Kozmik updated JBFORUMS-123:
------------------------------------

    Fix Version/s: 1.0.0 Alpha

Forgot to set Fix Version

> On preview topic view "Powered by JBoss Portal" tag flies around
> ----------------------------------------------------------------
>
>                 Key: JBFORUMS-123
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-123
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>
> While creating topic with preview the theme tag "Powered by JBoss Portal / Theme by ***" flies over forums.

-- 
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

        


From jira-events at jboss.com  Sat Sep 23 18:13:01 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Sat, 23 Sep 2006 18:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-124) Repair links to
 communicators, private message and e-mail
In-Reply-To: <30912966.1159038061046.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13726449.1159049581329.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-124?page=all ]

Ryszard Kozmik resolved JBFORUMS-124.
-------------------------------------

    Resolution: Done

> Repair links to communicators, private message and e-mail
> ---------------------------------------------------------
>
>                 Key: JBFORUMS-124
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-124
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Alpha
>
>          Time Spent: 3 hours
>
> After adding all information for user about his/her communicators, e-mail etc. TopicView and UserView is showing exceptions connected with generating wrong URL structure for communicators/e-mail buttons.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 00:40:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 00:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
Message-ID: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>

TransactionManager service config in services/config still refers to ArjunaTS
-----------------------------------------------------------------------------

                 Key: JBTM-129
                 URL: http://jira.jboss.com/jira/browse/JBTM-129
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Jonathan Halliday
            Priority: Minor
             Fix For: 4.4


So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 01:52:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 01:52:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
In-Reply-To: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17830911.1159077122111.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-128?page=comments#action_12343896 ] 
            
Mark Little commented on JBTM-128:
----------------------------------

This is a result of using interoposition on a remote transaction manager: the TM is not local so there will be no BasicAction instance. The code needs to duplicate the contents of the ClassCastException to cover this:

try
			{
				/*
				 * If this is an imported transaction and we have just performed
				 * interposition, then register a purely local Synchronization.
				 * This gets us over a performance issue with JacORB.
				 */

				theTx = (TwoPhaseCoordinator) BasicAction.Current();

                                if (theTx != null) // TM is local
				    theTx.addSynchronization(new LocalCleanupSynchronization(this));
                                else
                                    registerSynchronization(new CleanupSynchronization(this));
			}
			catch (ClassCastException ex)
			{
				/*
				 * Not a local/interposed transaction.
				 */

				registerSynchronization(new CleanupSynchronization(this));
			}

> warning with TransactionManager interface in JTS with external TM
> -----------------------------------------------------------------
>
>                 Key: JBTM-128
>                 URL: http://jira.jboss.com/jira/browse/JBTM-128
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
>            Reporter: Jonathan Halliday
>         Assigned To: Mark Little
>
> When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:
> 2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
> java.lang.NullPointerException
>         at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
>         at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)
> This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.
> Test code to reproduce warning:
>         System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
>         System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
>         ORB myORB = ORB.getInstance("ServerSide");
>         OA myOA = OA.getRootOA(myORB);
>         myORB.initORB(args, null);
>         myOA.initOA();
>         javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
>         transactionManager.begin();
>         transactionManager.commit();

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 01:55:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 01:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
In-Reply-To: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9893211.1159077301523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-128?page=all ]

Mark Little updated JBTM-128:
-----------------------------

    Fix Version/s: 4.2.2

> warning with TransactionManager interface in JTS with external TM
> -----------------------------------------------------------------
>
>                 Key: JBTM-128
>                 URL: http://jira.jboss.com/jira/browse/JBTM-128
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
>            Reporter: Jonathan Halliday
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:
> 2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
> java.lang.NullPointerException
>         at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
>         at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)
> This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.
> Test code to reproduce warning:
>         System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
>         System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
>         ORB myORB = ORB.getInstance("ServerSide");
>         OA myOA = OA.getRootOA(myORB);
>         myORB.initORB(args, null);
>         myOA.initOA();
>         javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
>         transactionManager.begin();
>         transactionManager.commit();

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 01:55:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 01:55:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-128) warning with
 TransactionManager interface in JTS with external TM
In-Reply-To: <26996825.1158932941080.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7350386.1159077302065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-128?page=all ]

Mark Little closed JBTM-128.
----------------------------

    Resolution: Done

> warning with TransactionManager interface in JTS with external TM
> -----------------------------------------------------------------
>
>                 Key: JBTM-128
>                 URL: http://jira.jboss.com/jira/browse/JBTM-128
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: TS 4.2.1 with JacORB on jdk 1.5.0_07, fedora core 5 linux
>            Reporter: Jonathan Halliday
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> When using JTS with external transaction manager and accessing transaction via javax.transaction.TransactionManager interface, an empty transaction generates a warning:
> 2006-09-22 14:35:10,928 [main] WARN  com.arjuna.ats.jta.logging.loggerI18N - [com.arjuna.ats.internal.jta.transaction.jts.syncproblem] [com.arjuna.ats.internal.jta.transaction.jts.syncproble] - cleanup synchronization failed to register:
> java.lang.NullPointerException
>         at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.<init>(TransactionImple.java:136)
>         at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.begin(BaseTransaction.java:128)
> This does not occur when using a local transaction manager or managing the transaction through OTSManager.get_current instead.
> Test code to reproduce warning:
>         System.setProperty("com.arjuna.ats.jta.jtaTMImplementation","com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple");
>         System.setProperty("com.arjuna.ats.jta.jtaUTImplementation","com.arjuna.ats.internal.jta.transaction.jts.UserTransactionImple");
>         ORB myORB = ORB.getInstance("ServerSide");
>         OA myOA = OA.getRootOA(myORB);
>         myORB.initORB(args, null);
>         myOA.initOA();
>         javax.transaction.TransactionManager transactionManager = com.arjuna.ats.jta.TransactionManager.transactionManager();
>         transactionManager.begin();
>         transactionManager.commit();

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:37:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
In-Reply-To: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22789304.1159079821407.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-129?page=all ]

Mark Little reassigned JBTM-129:
--------------------------------

    Assignee: Mark Little  (was: Jonathan Halliday)

> TransactionManager service config in services/config still refers to ArjunaTS
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-129
>                 URL: http://jira.jboss.com/jira/browse/JBTM-129
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:37:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
In-Reply-To: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26651713.1159079821566.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-129?page=all ]

Mark Little updated JBTM-129:
-----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)

> TransactionManager service config in services/config still refers to ArjunaTS
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-129
>                 URL: http://jira.jboss.com/jira/browse/JBTM-129
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-71) Bank example still
 refers to ArjunaTS
Message-ID: <32128541.1159081081253.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-71?page=comments#action_12343898 ] 
            
Mark Little commented on JBTM-71:
---------------------------------

So did TxStats, recoveryservice.conf, recoverymanagerservice.sh and many other files.

> Bank example still refers to ArjunaTS
> -------------------------------------
>
>                 Key: JBTM-71
>                 URL: http://jira.jboss.com/jira/browse/JBTM-71
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 02:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 02:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-71) Bank example still
 refers to ArjunaTS
Message-ID: <1188651.1159081081408.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-71?page=all ]

Mark Little updated JBTM-71:
----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.)])

> Bank example still refers to ArjunaTS
> -------------------------------------
>
>                 Key: JBTM-71
>                 URL: http://jira.jboss.com/jira/browse/JBTM-71
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:22:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-71) Bank example still
 refers to ArjunaTS
Message-ID: <4603331.1159082521767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-71?page=all ]

Mark Little closed JBTM-71.
---------------------------

    Resolution: Done

> Bank example still refers to ArjunaTS
> -------------------------------------
>
>                 Key: JBTM-71
>                 URL: http://jira.jboss.com/jira/browse/JBTM-71
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:22:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-129) TransactionManager
 service config in services/config still refers to ArjunaTS
In-Reply-To: <20253518.1159072801092.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29952887.1159082521924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-129?page=all ]

Mark Little closed JBTM-129.
----------------------------

    Resolution: Done

> TransactionManager service config in services/config still refers to ArjunaTS
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-129
>                 URL: http://jira.jboss.com/jira/browse/JBTM-129
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> So does the Recovery Manager equivalent.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:22:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-88) Patch for making
 source compilable with JDK1.5.0
Message-ID: <26753802.1159082522799.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-88?page=all ]

Mark Little reassigned JBTM-88:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Patch for making source compilable with JDK1.5.0
> ------------------------------------------------
>
>                 Key: JBTM-88
>                 URL: http://jira.jboss.com/jira/browse/JBTM-88
>             Project: JBoss Transaction Manager
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: Java
>            Reporter: Lorenz Froihofer
>         Assigned To: Jonathan Halliday
>         Attachments: jdk1.5.0.diff
>
>
> This patch makes the JBossTS sources compilable with JDK1.5.0. It was created by performing a diff against the sources provided in jbossts-full-4.2.1Beta1-src.zip

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:25:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-28) Replace existing
 JBoss transaction implementation in JBoss 5.0 with local JTA
Message-ID: <1948226.1159082701938.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-28?page=all ]

Mark Little reassigned JBTM-28:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Replace existing JBoss transaction implementation in JBoss 5.0 with local JTA
> -----------------------------------------------------------------------------
>
>                 Key: JBTM-28
>                 URL: http://jira.jboss.com/jira/browse/JBTM-28
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation, WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.6
>
>
> No separate plugin: default JTA implementation out-of-the-box.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:28:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-75) Update transactional
 JDBC driver to support JDBC 3 methods.
Message-ID: <15891063.1159082881344.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-75?page=all ]

Mark Little reassigned JBTM-75:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Update transactional JDBC driver to support JDBC 3 methods.
> -----------------------------------------------------------
>
>                 Key: JBTM-75
>                 URL: http://jira.jboss.com/jira/browse/JBTM-75
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>            Priority: Minor
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:28:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-88) Patch for making
 source compilable with JDK1.5.0
Message-ID: <27203193.1159082881522.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-88?page=all ]

Mark Little updated JBTM-88:
----------------------------

    Fix Version/s: 4.4

> Patch for making source compilable with JDK1.5.0
> ------------------------------------------------
>
>                 Key: JBTM-88
>                 URL: http://jira.jboss.com/jira/browse/JBTM-88
>             Project: JBoss Transaction Manager
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: Java
>            Reporter: Lorenz Froihofer
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>         Attachments: jdk1.5.0.diff
>
>
> This patch makes the JBossTS sources compilable with JDK1.5.0. It was created by performing a diff against the sources provided in jbossts-full-4.2.1Beta1-src.zip

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-47) Tidy up the online
	manuals
Message-ID: <30150164.1159083241210.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-47?page=all ]

Mark Little updated JBTM-47:
----------------------------

    Priority: Minor  (was: Major)

> Tidy up the online manuals
> --------------------------
>
>                 Key: JBTM-47
>                 URL: http://jira.jboss.com/jira/browse/JBTM-47
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation, Documentation
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>
> The online manuals (html) were generated from Word (SaveAs->HTML[Filtered]) and it hasn't done a great job. For a start, tabs are represented as ?. We need to fix this so that the presentation is consistent with the pdf manuals.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-72) Trail map neglects to
 remind reader to start recovery manager
Message-ID: <21954542.1159083241827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-72?page=all ]

Mark Little reassigned JBTM-72:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> Trail map neglects to remind reader to start recovery manager
> -------------------------------------------------------------
>
>                 Key: JBTM-72
>                 URL: http://jira.jboss.com/jira/browse/JBTM-72
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.4
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:37:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26027095.1159083421780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little updated JBTM-110:
-----------------------------

    Priority: Minor  (was: Major)

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16656693.1159084141506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little closed JBTM-110.
----------------------------

    Resolution: Cannot Reproduce Bug

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5336679.1159084141695.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little reopened JBTM-110:
------------------------------

             

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25110162.1159084141827.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little updated JBTM-110:
-----------------------------

    Fix Version/s: 4.2.2

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 03:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 03:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-110) Fix typo in timeout
 section of manual
In-Reply-To: <27790599.1154100671327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5645359.1159084141957.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-110?page=all ]

Mark Little closed JBTM-110.
----------------------------

    Resolution: Done

> Fix typo in timeout section of manual
> -------------------------------------
>
>                 Key: JBTM-110
>                 URL: http://jira.jboss.com/jira/browse/JBTM-110
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> Comment:
> looking at the doc file, page 2, do you think it is a typo in teh configuration:
> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value=" NORMAL"/>
> there is a space BEFORE the NORMAL tag i.e. " NORMAL"

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-113) Move timeout text
	from JTS to core
In-Reply-To: <24125928.1154260211382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4159775.1159084862056.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-113?page=all ]

Mark Little updated JBTM-113:
-----------------------------

    Fix Version/s: 4.2.2

> Move timeout text from JTS to core
> ----------------------------------
>
>                 Key: JBTM-113
>                 URL: http://jira.jboss.com/jira/browse/JBTM-113
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-113) Move timeout text from
	JTS to core
In-Reply-To: <24125928.1154260211382.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22287782.1159084862223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-113?page=all ]

Mark Little closed JBTM-113.
----------------------------

    Resolution: Done

> Move timeout text from JTS to core
> ----------------------------------
>
>                 Key: JBTM-113
>                 URL: http://jira.jboss.com/jira/browse/JBTM-113
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-73) Update trailmap text
 to remove Arjuna references
Message-ID: <28658340.1159084862369.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-73?page=all ]

Mark Little updated JBTM-73:
----------------------------

    Fix Version/s: 4.2.2

> Update trailmap text to remove Arjuna references
> ------------------------------------------------
>
>                 Key: JBTM-73
>                 URL: http://jira.jboss.com/jira/browse/JBTM-73
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>
> Trailmap text still talks about ArjunaTS.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:01:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:01:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-73) Update trailmap text to
 remove Arjuna references
Message-ID: <4873459.1159084862591.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-73?page=all ]

Mark Little closed JBTM-73.
---------------------------

    Resolution: Done

> Update trailmap text to remove Arjuna references
> ------------------------------------------------
>
>                 Key: JBTM-73
>                 URL: http://jira.jboss.com/jira/browse/JBTM-73
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Trailmap text still talks about ArjunaTS.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:16:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-96) XARecoveryModule does
 not use I18N logger in all info cases
In-Reply-To: <18100816.1152614531748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30571961.1159085761966.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-96?page=all ]

Mark Little updated JBTM-96:
----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)

> XARecoveryModule does not use I18N logger in all info cases
> -----------------------------------------------------------
>
>                 Key: JBTM-96
>                 URL: http://jira.jboss.com/jira/browse/JBTM-96
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:22:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-96) XARecoveryModule does
 not use I18N logger in all info cases
In-Reply-To: <18100816.1152614531748.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19888203.1159086121994.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-96?page=all ]

Mark Little closed JBTM-96.
---------------------------

    Resolution: Done

> XARecoveryModule does not use I18N logger in all info cases
> -----------------------------------------------------------
>
>                 Key: JBTM-96
>                 URL: http://jira.jboss.com/jira/browse/JBTM-96
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 20 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:25:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-85) BasicXARecovery
 example class is broken
Message-ID: <22282843.1159086301799.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-85?page=all ]

Mark Little updated JBTM-85:
----------------------------

    Fix Version/s: 4.2.2

> BasicXARecovery example class is broken
> ---------------------------------------
>
>                 Key: JBTM-85
>                 URL: http://jira.jboss.com/jira/browse/JBTM-85
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, Documentation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> The BasicXARecovery example class in the distribution is broken. When getting the attributes from the property file, the line:
>  String dynamicClass = new String(dbTag+user+dynamicClassTag);
> should be:
>     String dynamicClass = new String(dbTag+number+dynamicClassTag);

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:31:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-85) BasicXARecovery example
 class is broken
Message-ID: <29915965.1159086661805.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-85?page=all ]

Mark Little closed JBTM-85.
---------------------------

    Resolution: Done

> BasicXARecovery example class is broken
> ---------------------------------------
>
>                 Key: JBTM-85
>                 URL: http://jira.jboss.com/jira/browse/JBTM-85
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, Documentation
>    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
>
> The BasicXARecovery example class in the distribution is broken. When getting the attributes from the property file, the line:
>  String dynamicClass = new String(dbTag+user+dynamicClassTag);
> should be:
>     String dynamicClass = new String(dbTag+number+dynamicClassTag);

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-82) Make sure that
 xaRecoveryNode is mentioned in setup
Message-ID: <13644019.1159086841720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-82?page=all ]

Mark Little updated JBTM-82:
----------------------------

    Fix Version/s: 4.2.2

> Make sure that xaRecoveryNode is mentioned in setup
> ---------------------------------------------------
>
>                 Key: JBTM-82
>                 URL: http://jira.jboss.com/jira/browse/JBTM-82
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:34:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-82) Make sure that
 xaRecoveryNode is mentioned in setup
Message-ID: <28955164.1159086841931.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-82?page=all ]

Mark Little closed JBTM-82.
---------------------------

    Resolution: Done

> Make sure that xaRecoveryNode is mentioned in setup
> ---------------------------------------------------
>
>                 Key: JBTM-82
>                 URL: http://jira.jboss.com/jira/browse/JBTM-82
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    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
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:37:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-66) "Already marked for
 rollback" Exception could include original cause
Message-ID: <27290147.1159087022698.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-66?page=all ]

Mark Little reassigned JBTM-66:
-------------------------------

    Assignee: Jonathan Halliday  (was: Mark Little)

> "Already marked for rollback" Exception could include original cause
> --------------------------------------------------------------------
>
>                 Key: JBTM-66
>                 URL: http://jira.jboss.com/jira/browse/JBTM-66
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>         Environment: JBoss 4.0.4.CR2
>            Reporter: Richard Kennard
>         Assigned To: Jonathan Halliday
>            Priority: Optional
>             Fix For: 4.6
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> First up, thank you for providing such a wondefully stable implementation! I have a small feature request:
> At present whenever a, say, SFSB throws a RuntimeException, JTA goes into 'rollback' mode. From then on, anyone who tries to do any further work (including when the SessionContext tries to remove the rolled back SFSB) will trigger a different RuntimeException saying, in short, 'Already marked for rollback'.
> It would be very helpful if the 'Already marked for rollback' Exception could include, as its getCause (which is standard as of JDK 1.4), the original exception that started off the rollback? At present we are often left with the situation where all the original caller gets back is a 'Already marked for rollback' Exception, and there is no way to 'drill down' to find what the original cause was.
> Of course, you could also argue that the SessionContext should be smarter about trying to remove rolled back EJBs.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:37:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:37:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-66) "Already marked for
 rollback" Exception could include original cause
Message-ID: <23102284.1159087022896.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-66?page=all ]

Mark Little updated JBTM-66:
----------------------------

        Fix Version/s: 4.6
    Affects Version/s: 4.2
                           (was: 4.4)

> "Already marked for rollback" Exception could include original cause
> --------------------------------------------------------------------
>
>                 Key: JBTM-66
>                 URL: http://jira.jboss.com/jira/browse/JBTM-66
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>         Environment: JBoss 4.0.4.CR2
>            Reporter: Richard Kennard
>         Assigned To: Jonathan Halliday
>            Priority: Optional
>             Fix For: 4.6
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> First up, thank you for providing such a wondefully stable implementation! I have a small feature request:
> At present whenever a, say, SFSB throws a RuntimeException, JTA goes into 'rollback' mode. From then on, anyone who tries to do any further work (including when the SessionContext tries to remove the rolled back SFSB) will trigger a different RuntimeException saying, in short, 'Already marked for rollback'.
> It would be very helpful if the 'Already marked for rollback' Exception could include, as its getCause (which is standard as of JDK 1.4), the original exception that started off the rollback? At present we are often left with the situation where all the original caller gets back is a 'Already marked for rollback' Exception, and there is no way to 'drill down' to find what the original cause was.
> Of course, you could also argue that the SessionContext should be smarter about trying to remove rolled back EJBs.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:43:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-106) log if
 setTransactionTimeout on XAResource fails
In-Reply-To: <7964029.1153926971381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16042709.1159087381732.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-106?page=all ]

Mark Little updated JBTM-106:
-----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.6)

> log if setTransactionTimeout on XAResource fails
> ------------------------------------------------
>
>                 Key: JBTM-106
>                 URL: http://jira.jboss.com/jira/browse/JBTM-106
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Trivial
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:46:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-106) log if
 setTransactionTimeout on XAResource fails
In-Reply-To: <7964029.1153926971381.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10390962.1159087561930.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-106?page=all ]

Mark Little closed JBTM-106.
----------------------------

    Resolution: Done

> log if setTransactionTimeout on XAResource fails
> ------------------------------------------------
>
>                 Key: JBTM-106
>                 URL: http://jira.jboss.com/jira/browse/JBTM-106
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Trivial
>             Fix For: 4.2.2
>
>          Time Spent: 10 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:46:02 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-121) Check recovery
In-Reply-To: <8382747.1157556211028.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9017545.1159087562103.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-121?page=all ]

Mark Little reassigned JBTM-121:
--------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> Check recovery
> --------------
>
>                 Key: JBTM-121
>                 URL: http://jira.jboss.com/jira/browse/JBTM-121
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.4
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-80) consistent naming for
	jars
Message-ID: <3724698.1159087741367.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-80?page=all ]

Mark Little updated JBTM-80:
----------------------------

        Fix Version/s: 4.4
    Affects Version/s: 4.2

> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:49:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-80) consistent naming for
	jars
Message-ID: <32909985.1159087741544.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-80?page=all ]

Mark Little reassigned JBTM-80:
-------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 04:58:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 04:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-118) JTA manual example on
 transactional driver is out of date.
In-Reply-To: <16502287.1155290772947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4174587.1159088281325.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-118?page=all ]

Mark Little updated JBTM-118:
-----------------------------

    Fix Version/s: 4.2.2
                       (was: 4.4)

> JTA manual example on transactional driver is out of date.
> ----------------------------------------------------------
>
>                 Key: JBTM-118
>                 URL: http://jira.jboss.com/jira/browse/JBTM-118
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Optional
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:01:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-118) JTA manual example on
 transactional driver is out of date.
In-Reply-To: <16502287.1155290772947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10934714.1159088461445.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-118?page=all ]

Mark Little closed JBTM-118.
----------------------------

    Resolution: Done

> JTA manual example on transactional driver is out of date.
> ----------------------------------------------------------
>
>                 Key: JBTM-118
>                 URL: http://jira.jboss.com/jira/browse/JBTM-118
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Optional
>             Fix For: 4.2.2
>
>          Time Spent: 20 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:01:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-122) Requalify WS-TX 1.0
 interop against IBM/Microsoft endpoints
In-Reply-To: <33145092.1157558490997.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16400844.1159088461599.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-122?page=all ]

Mark Little updated JBTM-122:
-----------------------------

    Fix Version/s: 4.2.2

> Requalify WS-TX 1.0 interop against IBM/Microsoft endpoints
> -----------------------------------------------------------
>
>                 Key: JBTM-122
>                 URL: http://jira.jboss.com/jira/browse/JBTM-122
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:01:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sun, 24 Sep 2006 05:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-81) Delay start of
	recovery manager
Message-ID: <26261048.1159088461775.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-81?page=all ]

Mark Little updated JBTM-81:
----------------------------

    Fix Version/s: 4.2.2

> Delay start of recovery manager
> -------------------------------
>
>                 Key: JBTM-81
>                 URL: http://jira.jboss.com/jira/browse/JBTM-81
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace:
> 10:52:35,529 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\
> l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource
> java.io.StreamCorruptedException: unexpected end of block data
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\
> Module.java:178)
> This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:56:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 05:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-780) PojoCache to use
 pojocache-aop.xml
Message-ID: <27689009.1159091761416.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to use pojocache-aop.xml
----------------------------------

                 Key: JBCACHE-780
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-780
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


Previously, we have always use jboss-aop.xml as the configuration file for PojoCache and JBoss Aop. This is not adequate in 2.0 anymore becuase we have annotation plus additional interceptors stack and Obervable pattern. Therefore, I have decided to rename it into pojocache-aop.xml for PojoCache specific configuration.

If there is additional user-defined aop.xml fiel, e.g., via non-annotated way, then it can be named under user-aop.xml. From JBoss Aop point of view, all we need is to define the system property jboss.aop.path to include multiple *-aop.xml files.


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 05:56:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 05:56:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-780) PojoCache to use
 pojocache-aop.xml
In-Reply-To: <27689009.1159091761416.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25929889.1159091761571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-780?page=all ]

Ben Wang resolved JBCACHE-780.
------------------------------

    Resolution: Done

> PojoCache to use pojocache-aop.xml
> ----------------------------------
>
>                 Key: JBCACHE-780
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-780
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Previously, we have always use jboss-aop.xml as the configuration file for PojoCache and JBoss Aop. This is not adequate in 2.0 anymore becuase we have annotation plus additional interceptors stack and Obervable pattern. Therefore, I have decided to rename it into pojocache-aop.xml for PojoCache specific configuration.
> If there is additional user-defined aop.xml fiel, e.g., via non-annotated way, then it can be named under user-aop.xml. From JBoss Aop point of view, all we need is to define the system property jboss.aop.path to include multiple *-aop.xml files.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 08:23:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 08:23:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
Message-ID: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>

org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
---------------------------------------------------------------------------------------------

                 Key: JBCOMMON-10
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
             Project: JBoss Common
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.0.0.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 08:27:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 08:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
In-Reply-To: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7161163.1159100821267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-10?page=all ]

Scott M Stark updated JBCOMMON-10:
----------------------------------

    Fix Version/s: 1.0.0.GA
                   2.0.1.GA

> org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-10
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.0.0.CR1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>
> At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 08:27:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 08:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
In-Reply-To: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24365287.1159100821440.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-10?page=all ]

Scott M Stark updated JBCOMMON-10:
----------------------------------

    Affects Version/s: 2.0.0.GA
                       1.0.0.CR1
                           (was: 1.0.0.GA)

> org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-10
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.0.0.CR1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>
> At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-931) jBPM Integration
	for CMS
Message-ID: <4829962.1159104361459.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-931?page=all ]

Roy Russo reassigned JBPORTAL-931:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> jBPM Integration for CMS
> ------------------------
>
>                 Key: JBPORTAL-931
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-931
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Roy Russo
>         Assigned To: Sohil Shah
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-372) Basic Publish
 Approval Workflow
Message-ID: <12193380.1159104361795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-372?page=all ]

Roy Russo reassigned JBPORTAL-372:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> Basic Publish Approval Workflow
> -------------------------------
>
>                 Key: JBPORTAL-372
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-372
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: James Williams
>         Assigned To: Sohil Shah
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>
> Optional feature which mandates that  content changes must flow through a simple approval process that involves a Publisher and one or more Managers. Once the publisher makes a content change an email approval request should be sent to the manager list. The content change will not be made available to readers until all Managers approve the change.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-532) Define CMS
	security
Message-ID: <20822762.1159104362102.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-532?page=all ]

Roy Russo reassigned JBPORTAL-532:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> Define CMS security
> -------------------
>
>                 Key: JBPORTAL-532
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-532
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Sohil Shah
>             Fix For: 2.6.Alpha1
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> Explore the different possbilities of the cms security :
> - define what resources are secured (it should be directories and content)
> - define the security model : the different actions on nodes and their relationship accross the resources (i.e what implies what between different resources)
> - see if the new portal security module can handle that
> - where to apply runtime checks

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:26:02 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:26:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-328) CMS security
Message-ID: <2986445.1159104362381.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-328?page=all ]

Roy Russo reassigned JBPORTAL-328:
----------------------------------

    Assignee: Sohil Shah  (was: Roy Russo)

> CMS security
> ------------
>
>                 Key: JBPORTAL-328
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-328
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal CMS
>    Affects Versions: 2.6 Final
>            Reporter: Julien Viet
>         Assigned To: Sohil Shah
>             Fix For: 2.6.Alpha1
>
>
> Improve the current CMS security.
> No check is done at the CMSPortlet level, this is a important missing feature.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 09:29:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sun, 24 Sep 2006 09:29:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-964) disorder display
	in 800*600
In-Reply-To: <5627778.1153472051630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1007916.1159104541333.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-964?page=all ]

Roy Russo resolved JBPORTAL-964.
--------------------------------

    Fix Version/s: 2.6.Alpha1
       Resolution: Done

> disorder display in 800*600
> ---------------------------
>
>                 Key: JBPORTAL-964
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-964
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Core
>    Affects Versions: 2.2.1 Final, 2.0 Branch, 2.0.2 Final, 2.2 Branch, 2.4 Final
>         Environment: windowxp(800*600) ,ie6
>            Reporter: &#21556;&#22869;&#38596;
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>         Attachments: screenshot-1.jpg
>
>


-- 
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

        


From jira-events at jboss.com  Sun Sep 24 10:11:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Sun, 24 Sep 2006 10:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-10)
 org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in
 equality/hashCode
In-Reply-To: <14803356.1159100581223.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14875286.1159107061232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-10?page=all ]

Scott M Stark closed JBCOMMON-10.
---------------------------------

    Resolution: Done

> org.jboss.net.sockets.DefaultSocketFactory does not consider bindAddress in equality/hashCode
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBCOMMON-10
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-10
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0.GA, 1.0.0.CR1
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>
> At least the sun rmi implementation decides on creation of a listening port based on uniqueness of the server socket factory associated with the stub. The org.jboss.net.sockets.DefaultSocketFactory is not considering the bindAddress setting, and so it cannot be used to export the same object multiple times on different interfaces. The DefaultSocketFactory needs to consider the bindAddress in equals and hashCode.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 14:11:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 14:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <8539906.1159121461506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis updated JBAS-3683:
-------------------------------------

    Attachment: attributes.mib

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: attributes.mib, snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 14:14:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 14:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3683)
 snmp-adaptor.sar/attributes.mib MIB syntax errors
Message-ID: <6955734.1159121641162.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3683?page=all ]

Dimitris Andreadis closed JBAS-3683.
------------------------------------

    Resolution: Done

I've attached the corrected MIB in case you want to run it through the compiler again. In fact, we have little experience and resources in developing a decent MIB so we could use some help if you are interested.

Thanks again.

> snmp-adaptor.sar/attributes.mib MIB syntax errors
> -------------------------------------------------
>
>                 Key: JBAS-3683
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3683
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Using NET-SNMP 5.2.3 to parse the MIB
>            Reporter: Gerald Turner
>         Assigned To: Dimitris Andreadis
>            Priority: Trivial
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: attributes.mib, snmp-adaptor-attributes.mib.patch.gz
>
>
> Trivial patch to fix some syntax errors in attributes.mib.  Things like the operator ":: =" cannot include a space and STATUS must be defined in an OBJECT-TYPE.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 14:59:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 14:59:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3346)
 org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase
 causes 1.5 BEA JVM to core dump
Message-ID: <22304321.1159124341558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3346?page=all ]

Dimitris Andreadis closed JBAS-3346.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Won't Fix

By reading the related bugzilla/redhat entry it is clear the core dump appears only using the 62-bit BEA JDK, and doesn't happen using the 32-bit BEA JDK.

I don't think there is much we can do in the jboss codebase about this.

> org.jboss.test.cmp2.batchcascadedelete.test.BatchCascadeDeleteUnitTestCase causes 1.5 BEA JVM to core dump
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3346
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3346
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: CMP service, Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: RHEL 4, x86_64 processor, BEA 1,5 JDK
>            Reporter: Len DiMaggio
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>
> With this JDK:
> java version "1.5.0_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
> BEA JRockit(R) (build dra-45238-20050523-2021-linux-x86_64, R25.2.0-28)
> And this test from the JBoss 4.0.4/GA test suite (download from jboss.com) - the test causes a code dump when it executes line 62.
>      1	/*
>      2	* JBoss, Home of Professional Open Source
>      3	* Copyright 2005, JBoss Inc., and individual contributors as indicated
>      4	* by the @authors tag. See the copyright.txt in the distribution for a
>      5	* full listing of individual contributors.
>      6	*
>      7	* This is free software; you can redistribute it and/or modify it
>      8	* under the terms of the GNU Lesser General Public License as
>      9	* published by the Free Software Foundation; either version 2.1 of
>     10	* the License, or (at your option) any later version.
>     11	*
>     12	* This software is distributed in the hope that it will be useful,
>     13	* but WITHOUT ANY WARRANTY; without even the implied warranty of
>     14	* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>     15	* Lesser General Public License for more details.
>     16	*
>     17	* You should have received a copy of the GNU Lesser General Public
>     18	* License along with this software; if not, write to the Free
>     19	* Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
>     20	* 02110-1301 USA, or see the FSF site: http://www.fsf.org.
>     21	*/
>     22	package org.jboss.test.cmp2.batchcascadedelete.test;
>     23	
>     24	import org.jboss.test.JBossTestCase;
>     25	import org.jboss.test.cmp2.batchcascadedelete.ejb.Child;
>     26	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildHome;
>     27	import org.jboss.test.cmp2.batchcascadedelete.ejb.ChildUtil;
>     28	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildHome;
>     29	import org.jboss.test.cmp2.batchcascadedelete.ejb.GrandchildUtil;
>     30	import org.jboss.test.cmp2.batchcascadedelete.ejb.Parent;
>     31	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentHome;
>     32	import org.jboss.test.cmp2.batchcascadedelete.ejb.ParentUtil;
>     33	import junit.framework.Test;
>     34	
>     35	/**
>     36	 * @author <a href="mailto:alex at jboss.org">Alexey Loubyansky</a>
>     37	 * @version <tt>$Revision: 1.1.2.2 $</tt>
>     38	 */
>     39	public class BatchCascadeDeleteUnitTestCase
>     40	   extends JBossTestCase
>     41	{
>     42	   /**
>     43	    * Constructor for the JBossTestCase object
>     44	    *
>     45	    * @param name Test case name
>     46	    */
>     47	   public BatchCascadeDeleteUnitTestCase(String name)
>     48	   {
>     49	      super(name);
>     50	   }
>     51	
>     52	   public static Test suite() throws Exception
>     53	   {
>     54	      return JBossTestCase.getDeploySetup(BatchCascadeDeleteUnitTestCase.class, "cmp2-batchcascadedelete.jar");
>     55	   }
>     56	
>     57	   public void testCase4540() throws Exception
>     58	   {
>     59	      ParentHome parentHome = ParentUtil.getHome();
>     60	      Parent parent = parentHome.create("parent");
>     61	
>     62	      ChildHome childHome = ChildUtil.getHome();
>     63	      Child child = childHome.create( parent, "child");
>     64	
>     65	      GrandchildHome grandchildHome = GrandchildUtil.getHome();
>     66	
>     67	      // If you comment out the next line, then the call to child.remove() works fine.
>     68	      grandchildHome.create(child.getId(), "grandchild");
>     69	
>     70	      this is the test for non-null foreign key
>     71	      child.remove();
>     72	   }
>     73	}
> Here's the dump file:
> Linux x86_64-4as.lab.boston.redhat.com 2.6.9-39.ELsmp #1 SMP Thu Jun 1 18:01:55 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
> ===== BEGIN DUMP =============================================================
> JRockit dump produced after 0 days, 00:29:38 on Wed Jun 21 13:56:36 2006
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Error Message: Illegal memory access. [54]
> Signal info  : si_signo=12, si_code=-6
> Version      : BEA JRockit(R) R25.2.0-28 dra-45238-20050523-2021-linux-x86_64
> GC           : System optimized over throughput (initial strategy singleparpar)
>              : GC strategy for GC 4 was genparpar
>              : GC strategy for GC 5 was singleparpar
>              : GC strategy for GC 6 was genparpar
>              : GC strategy for GC 7 was singleparpar
>              : GC strategy for GC 8 was genparpar
>              : mmHeap->data = 0x20000000, mmHeap->top = 0x28000000
>              : mmStartCompaction = 0x21800000, mmEndCompaction = 0x22000000
> CPU          : Intel Pentium 4 SSE SSE2 NetBurst EM64T
> Number CPUs  : 2
> Tot Phys Mem : 4120244224
> OS version   : Red Hat Enterprise Linux AS release 4 (Nahant Update 4 Beta)
> Linux version 2.6.9-39.ELsmp (bhcompile at hs20-bc1-6.build.redhat.com) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-2)) #1 SMP Thu Jun 1 18:01:55 EDT 2006
> State        : JVM is running (Main thread has finished)
> Command Line : -Djrockit.launcher.type=jrockit.shipment -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dprogram.name=run.sh -Djava.endorsed.dirs=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/lib/endorsed org.jboss.Main -c all
> Environment  : JAVA_HOME=(null), java.home=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre, java.class.path=/opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/run.jar:/lib/tools.jar, java.library.path=/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64:/usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/../lib/amd64
> C Heap       : Good; no memory allocations have failed
> Registers (from context struct at 0x40e899f8/0x40e89a70):
> RAX = ffffffff00000010  RBX = 00000000f7bc5de8
> RCX = 00000000f7bc5df8  RDX = 00000000ffcb1bf3
> R8  = 000000000002feeb  R9  = 000000009090feeb
> R10 = 0000002a9b7aeed0  R11 = 0000002a9577893c
> R12 = 0000000040e89e58  R13 = 0000000000000001
> R14 = 0000000000000001  R15 = 0000002a9b7aed08
> RSI = 0000000020c8bb78  RDI = 00000000220b1108
> RSP = 0000000040e89eb0  RIP = 00000001009ccec8
> RBP = 00000000220b1108  RFL = 00000206
> CS = 0000 GS = 0000 FS = 0000
> Stack:
> 0000000040e89eb0: 0000000021ff0238 00000001009ccbb5 00000000220d6b28 0000000020c81130 0000000022078920 0000000021ff0238 
> 0000000040e89ee0: 0000000100000a22 0000000003c3d730 00000000220d6b40 0000000020c8bb48 0000000022078920 0000000021ff0238 
> 0000000040e89f10: 00000001009ca128 00000001009c9fdf 0000000022078920 0000000020c70cb0 00000000220b22a8 00000000220924a8 
> 0000000040e89f40: 0000000020c8bb48 0000000021ff0238 0000000022078920 0000000020c6ed78 00000001009c9c23 0000000020c6ee40 
> 0000000040e89f70: 0000000100000a45 000000000000001c 0000000021ff0238 0000000020c6ed78 0000000022078920 0000000021ff0238 
> 0000000040e89fa0: 00000001009c9b55 0000000020c137d8 00000001009c8e0f 0000000000000000 0000000022078920 0000000020b0b3b8 
> 0000000040e89fd0: 0000000021ff0238 0000000020c8b568 0000000000000000 0000000021ff0238 0000000020c137d8 0000000021ff0238 
> 0000000040e8a000: 0000000021ff0238 00000001009c8cb5 0000000020c0f3d8 00000001009c8bd4 0000000020c10a90 0000000003c064b0 
> 0000000040e8a030: 0000000021ff0238 0000000020c0f3d8 00000001009c8a8f 0000000003c057f0 0000000020a5ddb0 00000000220924a8 
> 0000000040e8a060: 00000001009c8296 0000000000000001 0000002a9b7aed08 000000010000090f 00000000005d7cd0 0000002a9b7aeed0 
> 0000000040e8a090: 00000000a6bf41f8 0000000020c0dca8 0000000021ff0238 0000000000000000 0000000020a5ddb0 0000000003bffb80 
> 0000000040e8a0c0: 0000000021ff0238 0000000000000000 0000000020a5ddb0 00000000220924a8 00000001009c7386 0000000020a5ddb0 
> 0000000040e8a0f0: 03c028209b7aed08 0000002a9b7aeed8 0000000020c0dca8 0000000000000000 00000000220924a8 0000000021ff0238 
> 0000000040e8a120: 0000000000000000 00000000220924a8 000000000000012c 0000002a9b7aeed0 0000000100000000 000000010002bdf0 
> 0000000040e8a150: 0000000020c08a38 0000000020a5ddb0 0000000100000a22 0000000003c00cf8 0000000000000001 00000000274b8c38 
> 0000000040e8a180: 0000000020c08a38 0000000021ff0238 00000001009c6da7 0000000100000a45 0000000020c0dca8 0000000021ff0238 
> 0000000040e8a1b0: 0000000000000000 0000000000000000 0000000021ff0238 00000001009c62a0 0000000021ff0238 0000000020c07368 
> 0000000040e8a1e0: 00000001009c612a 00000000005d7c90 0000000020c07368 0000000021ff0238 0000000021103b10 0000000000000000 
> 0000000040e8a210: 0000000021ff0238 0000000100000a45 000000000000001c 0000002a969f1010 0000000003bf6978 0000000020c05d48 
> 0000000040e8a240: 0000000021ff0238 00000001009c5b5f 0000000021ff0238 0000000000000000 0000000021ff4240 0000000020c05d48 
> 0000000040e8a270: 0000000021ff0238 0000000020b0b3b8 0000000021ff0238 00000001009c58b4 00000000210fb030 0000000040e8a3e0 
> 0000000040e8a2a0: 0000000020a5ddb0 00000001009c4f23 00000000269f9f90 0000000020b0b3b8 0000000021ff0238 0000000021033388 
> 0000000040e8a2d0: 0000010bf7bc5c80 00000000210fb030 0000002a00000001 0000000000000000 0000002a9b7aed08 0000002a956ad0b1 
> 0000000040e8a300: 000000000000029c 0000000002645f21 0000002a9b7aeec0 0000000040e8a598 0000000040e8a3e0 0000000040e8a560 
> 0000000040e8a330: 0000000100030068 0000000040e8a4f8 0000000040e8a3e0 00000001009c4b10 0000002a9b7aeb20 0000002a9b7aed08 
> 0000000040e8a360: 0000000000000001 0000000000000001 0000000040e8a3e0 0000002a9b7aed08 000000000064ca60 0000002a9560787a 
> 0000000040e8a390: 0000000000000002 0000002a956d3107 0000000103bb9370 000000000056aaa8 0000000040e8a500 0000002a9b7aee48 
> 0000000040e8a3c0: 0000002a9b7b3b00 0000002a956aca24 0000000003bb9370 0000000002643f80 0000002a9b7aee48 0000002a9b7aeec0 
> 0000000040e8a3f0: 0000000000000000 0000000100000000 0000000100000001 0000002a9b7aed28 0000000003bb9370 0000002a9b7aed08 
> 0000000040e8a420: 000000000056aaa8 0000000100000007 0000000200000001 0000000200000000 0000002a00000000 0000002a956c3228 
> 0000000040e8a450: 03bc261800000000 0000000002643f80 0000002a9b7aed08 0000002a9b7b3b00 0000002a9b7aee48 0000002a956c36f0 
> 0000000040e8a480: 0000000000000000 0000002a956c337c 0000002a956c36f0 0000000040e8a4f8 0000000040e8a500 0000000002643f80 
> 0000000040e8a4b0: 0000000000000001 0000002a9b7aee48 0000000000000000 0000002a9b7aed08 0000000002643f80 0000002a956c37c9 
> 0000000040e8a4e0: 011f3cc000000000 0000000040e8a4f8 000000010003af7a 0000002a9b7aeec8 0000000040e8a598 0000002a9b7aed08 
> 0000000040e8a510: 00000001001ecc8b 0000002a9b7aee58 0000002a9b7aeb20 0000000040e8a560 0000000000000001 0000000000000001 
> 0000000040e8a540: 0000002a9b7aed08 0000002a956cc14a 0000002a9b7aee48 000000010003c1e0 0000000000688b30 0000002a9b7aee48 
> 0000000040e8a570: 000000002192dec8 000000010003bfa7 0000000020b0b3b8 0000000021ff6d58 000000010003bea6 0000000021ff6be8 
> 0000000040e8a5a0: 0000000021ff6d58 0000000020b0b3b8 0000000021ff6be8 0000000100000001 0000000020b0b3b8 0000000020b0b3b8 
> 0000000040e8a5d0: 0000000021ff6be8 000000010005db3e 0000000021ff6be8 0000000021ff6d58 0000000020b0b3b8 0000000021ff6d98 
> 0000000040e8a600: 000000010003bd09 0000000021ff6be8 0000000021ff6be8 0000000021ff6be8 0000000020fa8d58 000000010003b2d5 
> 0000000040e8a630: 0000000021ff6be8 0000000020b0b3b8 0000000001939c68 0000000100003945 00000000200a1118 0000000025179958 
> 0000000040e8a660: 0000000000000001 000000000193de20 0000000021ff6c80 0000000020fa8d58 000000010023c5c8 0000000021ff6be8 
> 0000000040e8a690: 00000000ffffffff 0000000021ff6d10 0000000020ffd028 0000000021ff6c80 0000000020fa8d58 0000000020b0b3b8 
> Code:
> 00000001009ccdc8: 894890ff672533e8 c3d2f8252c8b48f3 0001025188b84803 ff6362c8e8000000 0e7ee82824748948 482824748b48ff67 
> 00000001009ccdf8: 00002a9b7ca2b8bf 26048b273c8b4800 7c8b48ff670fa3e8 0e16e826048b0824 0f0ee826048bff69 ee8948f78948ff67 
> 00000001009cce28: 90004d8b241c8948 50b848ff6bef21e8 9000000000010531 df8948ff63626be8 25048b4864f38948 28468948000000d8 
> 00000001009cce58: de8948ff647717e8 894890ff67249be8 ede81024748b48f3 85e8de8948ff6364 cccccccc90ff6724 8bfe8948f38948cf 
> 00000001009cce88: ffffffe0b848260c 480114ffffffffff 67b8c189c389de89 c1c889e9f7666666 89c2011fe8c104fa c82928c96bd189d8 
> 00000001009cceb8: 08768b48137fc085 1776084639d8f748 48c35b10c6748b48 127608463908768b 48c35b10c6748b48 000001009ccec6b8 
> 00000001009ccee8: 009cced6b848f400 ccccccf400000001 cccccccccccccccc 8b4840ec83485553 854820408b483846 4800000213840fc0 
> 00000001009ccf18: 4de838768b48f389 05e8f58948000002 8948c18948ff75bb 314830244c8948d8 44894838708b48db 0c8b20768b480824 
> 00000001009ccf48: e8ffff43e1e89026 24548b48ff63622c 89480824448b4830 244c8948ee8948f1 0093e910768b4828 8948304e8b480000 
> 00000001009ccf78: 8948d58948382474 8948cd2948302454 0c8b0824448948c6 48ffe4d635e89020 d53948d88948c289 480774c08548737c 
> 00000001009ccfa8: b84826eb38245c8b 00000000011df298 f38948ff6360f3e8 5c8948ff66b3dbe8 481024448b481024 48df894838245c8b 
> Loaded modules:
> (* denotes the module causing the exception)
> 0x400000-0x411037  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/bin/java
> 0x3a5dc00000-0x3a5dc0eff9  /lib64/tls/libpthread.so.0
> 0x3a5d400000-0x3a5d48459b  /lib64/tls/libm.so.6
> 0x3a5cf00000-0x3a5cf01c73  /lib64/libdl.so.2
> 0x3a5d100000-0x3a5d22ac59  /lib64/tls/libc.so.6
> 0x3a5cd00000-0x3a5cd1434f  /lib64/ld-linux-x86-64.so.2
> 0x2a95588000-0x2a957a660f  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/jrockit/libjvm.so
> 0x2a959e3000-0x2a959ecf13  /lib64/libnss_files.so.2
> 0x2a96c6f000-0x2a96c93473  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libjava.so
> 0x2a96d99000-0x2a96da5627  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libverify.so
> 0x3a62e00000-0x3a62e134eb  /lib64/libnsl.so.1
> 0x2a99d9f000-0x2a99db3fcf  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/libnet.so
> 0x2a99eb6000-0x2a99ebed33  /lib64/libnss_nis.so.2
> 0x2a99fc0000-0x2a99fc38a3  /lib64/libnss_dns.so.2
> 0x3a5e200000-0x3a5e210d9b  /lib64/libresolv.so.2
> 0x2a9b5c8000-0x2a9b5c897b  /usr/lib/jvm/java-1.5.0-bea-1.5.0.03/jre/lib/amd64/librmi.so
> "RMI TCP Connection(4)-192.168.7" id=149 idx=0xc8 tid=1088993632 lastJavaFrame=(nil)
> Thread Stack Trace:
> Additional information is available in:
>   /opt/jboss-4.0.4.GA-src/build/output/jboss-4.0.4.GA/bin/jrockit.15362.dump
> No core file will be created because core dumps have been
> disabled. To enable core dumping, try "ulimit -c unlimited"
> before starting JRockit again.
> If you see this dump, please open a support case with BEA and
> supply as much information as you can on your system setup and
> the program you were running. You can also search for solutions
> to your problem at http://forums.bea.com in
> the forum jrockit.developer.interest.general.
> Extended, platform specific info:
> libc release: 2.3.4-stable
> Elf headers:
> libc       ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5d11c4a0 PHOFF: 0x40 SHOFF: 0x13d5a8 EF: 0x0 HS: 64 PS: 56 PHN; 10 SS: 64 SHN: 69 STIDX: 66
> libpthread ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x3a5dc05620 PHOFF: 0x40 SHOFF: 0x12980 EF: 0x0 HS: 64 PS: 56 PHN; 9 SS: 64 SHN: 38 STIDX: 35
> libjvm     ehdrs: EI: 7f454c46020101000000000000000000 ET: 3 EM: 62 V: 1 ENTRY: 0x36c80 PHOFF: 0x40 SHOFF: 0x3106f0 EF: 0x0 HS: 64 PS: 56 PHN; 3 SS: 64 SHN: 22 STIDX: 19
> ===== END DUMP ===============================================================

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 15:02:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 15:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24821147.1159124521080.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3659?page=comments#action_12343912 ] 
            
Dimitris Andreadis commented on JBAS-3659:
------------------------------------------

Brian, we've started getting OOMEs in the testsuite runs, could this be related?

> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 15:08:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sun, 24 Sep 2006 15:08:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1740) Remote Connection
 does not get closed in case of sloppy client
Message-ID: <1528398.1159124881277.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1740?page=comments#action_12343913 ] 
            
Dimitris Andreadis commented on JBAS-1740:
------------------------------------------

Weston, u working on this for 4.0.5? The parent tasks doesn't have a fix release assigned.

> Remote Connection does not get closed in case of sloppy client
> --------------------------------------------------------------
>
>                 Key: JBAS-1740
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1740
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. 
> This can be solved rather easily, the finalize method of the Server part of the proxy should call close.
> Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called.
> This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work with.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 15:11:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Sun, 24 Sep 2006 15:11:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1740) Remote Connection
 does not get closed in case of sloppy client
Message-ID: <27973025.1159125061261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1740?page=all ]

Weston Price updated JBAS-1740:
-------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
                       (was: JBossAS-4.0.5.GA)

Modfied according to JCA roadmap meeting.

> Remote Connection does not get closed in case of sloppy client
> --------------------------------------------------------------
>
>                 Key: JBAS-1740
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1740
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.1 Final
>            Reporter: Michael Kopp
>         Assigned To: Weston Price
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta
>
>
> If the Client that gets a remote Connection (WrapperDataSourceService) does not close it properly (sloppy or crash), it will never be released again. 
> This can be solved rather easily, the finalize method of the Server part of the proxy should call close.
> Thus if the client object gets garbage collected (or the JVM dies), the server object (proxy) will be garbage collected and the finalize method called.
> This thing is that a sloppy or crashing client can occupy all available connections, leaving all other applications with no connection to work with.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 21:02:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 21:02:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-778) Refactor package
	distribution
In-Reply-To: <31189905.1159011901144.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23507969.1159146121047.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-778?page=all ]

Ben Wang resolved JBCACHE-778.
------------------------------

    Resolution: Done

> Refactor package distribution
> -----------------------------
>
>                 Key: JBCACHE-778
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-778
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> Per disucssion, we are refactoring the distribution package for release 2.0.
> 1. jboss-cache-core-dist.zip. Core edition that contains the tradition cache library.
>   - Only Cache (jboss-cache.jar) and supporting library
>   - Ref doc
>   - faq
>   - tutorial
> 2. jboss-cache-pojo-dist.zip. PojoCache edition. It has jboss-cache-core-dist.zip, plus
>   - pojocache.jar that contains the PojoCache lib
>   - additional JBoss Aop, trove, javassist, jboss-aop-jdk50.jar, qdox.jar
>   - PojoCache ref doc
>   - faq-pojo for PojoCache
>  
> 3. jboss-cache-all-dist.zip. Everything PojoCache has, plus
>  - javadoc
>  - src

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 21:05:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 21:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-781) PojoCache creates
 a separate pojocache.jar for distro
Message-ID: <14717249.1159146301455.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache creates a separate pojocache.jar for distro
-----------------------------------------------------

                 Key: JBCACHE-781
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-781
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Critical
             Fix For: 2.0.0


In 2.0 release, we have created a separate jar file for PojoCache only: pojocache.jar, while keeping jboss-cache.jar to core Cache library. PojoCache users will need to put both pojocache.jar and jboss-cache.jar in their class path.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 21:05:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 21:05:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-781) PojoCache creates
 a separate pojocache.jar for distro
In-Reply-To: <14717249.1159146301455.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27921653.1159146301583.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-781?page=all ]

Ben Wang resolved JBCACHE-781.
------------------------------

    Resolution: Done

> PojoCache creates a separate pojocache.jar for distro
> -----------------------------------------------------
>
>                 Key: JBCACHE-781
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-781
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Critical
>             Fix For: 2.0.0
>
>
> In 2.0 release, we have created a separate jar file for PojoCache only: pojocache.jar, while keeping jboss-cache.jar to core Cache library. PojoCache users will need to put both pojocache.jar and jboss-cache.jar in their class path.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 23:51:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 23:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-782) Rename
 Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
Message-ID: <20747207.1159156261115.JavaMail.jira@cloud.prod.atl2.jboss.com>

Rename Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
------------------------------------------------------------------------------

                 Key: JBCACHE-782
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-782
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Ben Wang
            Priority: Minor
             Fix For: 2.0.0


As agreed, we will rename this from useInterceptorMbeans to useMbean in Configuration. This flag will represent the generic JMX flag.

-- 
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

        


From jira-events at jboss.com  Sun Sep 24 23:51:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Sun, 24 Sep 2006 23:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-782) Rename
 Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
In-Reply-To: <20747207.1159156261115.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32763577.1159156261221.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-782?page=all ]

Ben Wang resolved JBCACHE-782.
------------------------------

    Resolution: Done

> Rename Configuration.useInterceptorMbeans flag to reflect generic JMX behavior
> ------------------------------------------------------------------------------
>
>                 Key: JBCACHE-782
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-782
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0
>
>
> As agreed, we will rename this from useInterceptorMbeans to useMbean in Configuration. This flag will represent the generic JMX flag.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:09:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 25 Sep 2006 01:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-9) Mavenize Security
	Build
In-Reply-To: <24504065.1158609301211.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18341006.1159160941201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-9?page=all ]

Anil Saldhana closed SECURITY-9.
--------------------------------

    Resolution: Done

First cut of maven pom.xml checked in.

The requisite jars are created in output/lib

As and when we obtain additional expertise in Maven2, cleanup/optmization etc can be done.

> Mavenize Security Build
> -----------------------
>
>                 Key: SECURITY-9
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-9
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> Need to convert the security build into a maven based build.
> Reference:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation
> https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:09:01 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Mon, 25 Sep 2006 01:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (SECURITY-9) Mavenize Security
	Build
In-Reply-To: <24504065.1158609301211.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5304641.1159160941398.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/SECURITY-9?page=comments#action_12343917 ] 
            
Anil Saldhana commented on SECURITY-9:
--------------------------------------

Forum Thread:http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90069

> Mavenize Security Build
> -----------------------
>
>                 Key: SECURITY-9
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-9
>             Project: JBoss Security
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JBossSX
>    Affects Versions: 2.0
>            Reporter: Anil Saldhana
>         Assigned To: Anil Saldhana
>             Fix For: 2.0
>
>
> Need to convert the security build into a maven based build.
> Reference:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=MavenBuildCreation
> https://svn.labs.jboss.org/labs/jbossbuild/trunk/projects/jboss/security/ (Prototype work by Ruel)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:46:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 25 Sep 2006 01:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-783) PojoCache to
 provide MBean interfaces
Message-ID: <19815578.1159163161304.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to provide MBean interfaces
-------------------------------------

                 Key: JBCACHE-783
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-783
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


In 2.0 release, since we are using delegation model for the core Cache, we can't no more rely on the underlying Cache to provide MBean interfaces. Instead, we are following the methodolody used in Cache. That is, we will have a .jmx.PojoCache class that has implemented the MBean interfaces and provide monitoring stats.

We will share the flag useMbean in Configuration object to activate MBean service.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 01:46:01 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Mon, 25 Sep 2006 01:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-783) PojoCache to
 provide MBean interfaces
In-Reply-To: <19815578.1159163161304.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30222126.1159163161411.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-783?page=all ]

Ben Wang resolved JBCACHE-783.
------------------------------

    Resolution: Done

> PojoCache to provide MBean interfaces
> -------------------------------------
>
>                 Key: JBCACHE-783
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-783
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: PojoCache
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>             Fix For: 2.0.0
>
>
> In 2.0 release, since we are using delegation model for the core Cache, we can't no more rely on the underlying Cache to provide MBean interfaces. Instead, we are following the methodolody used in Cache. That is, we will have a .jmx.PojoCache class that has implemented the MBean interfaces and provide monitoring stats.
> We will share the flag useMbean in Configuration object to activate MBean service.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 02:48:01 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Mon, 25 Sep 2006 02:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-355) Constructor
 injection of component dependencies
In-Reply-To: <24855290.1158605701220.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14969998.1159166881312.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-355?page=comments#action_12343918 ] 
            
Christian Bauer commented on JBSEAM-355:
----------------------------------------

I think we already have everything to do that by the way:

@Entity
@Table(name = "BID")
@org.hibernate.annotations.Entity(mutable = false)
@Name("bid")
public class Bid implements Serializable {
    ...
    /**
     * No-arg constructor for JavaBean tools.
     */
    public Bid() {}

    /**
     * Full constructor.
     *
     * @param amount
     * @param item
     * @param bidder
     */

    @Role(name="newBid", scope = ScopeType.CONVERSATION)
    public Bid(BigDecimal amount, @In Item item, @In("currentUser") User bidder) {
        this.amount = amount;
        this.item = item;
        this.bidder = bidder;
    }
    ...
}

> Constructor injection of component dependencies
> -----------------------------------------------
>
>                 Key: JBSEAM-355
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-355
>             Project: JBoss Seam
>          Issue Type: Feature Request
>            Reporter: Christian Bauer
>            Priority: Minor
>
> Take the registration example. The 'user' component is instantiated by Seam when JSF first looks for 'user' in a page. It is then put in the SESSION context (think CONVERSATION for other use cases of what I'm proposing). Seam uses the default constructor to instantiate the component. 
> Now imagine that some attributes of User are immutable and that the only way to set their values is through a different constructor. Also imagine that these values are actually present when Seam instantiates the 'user' component, e.g. in the current CONVERSATION. I'd like to tell Seam to call my constructor and use EL to bind the arguments.
> Without this feature, immutable properties need to have public setter methods that I call later in an action method to wire in the required attributes manually.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:27:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-325) task priority not set
	properly
Message-ID: <22629505.1159169221167.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-325?page=all ]

Tom Baeyens closed JBPM-325.
----------------------------

    Resolution: Done

> task priority not set properly
> ------------------------------
>
>                 Key: JBPM-325
>                 URL: http://jira.jboss.com/jira/browse/JBPM-325
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:30:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBPM-716) make the timer duedate
	optional
In-Reply-To: <16381613.1154586971316.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22832873.1159169401667.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-716?page=all ]

Tom Baeyens closed JBPM-716.
----------------------------

    Resolution: Done

> make the timer duedate optional
> -------------------------------
>
>                 Key: JBPM-716
>                 URL: http://jira.jboss.com/jira/browse/JBPM-716
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Core Engine
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>            Priority: Minor
>             Fix For: jBPM 3.1.3, jBPM 3.2 alpha 1
>
>
> now, it's not possible to have a timer without a dueDate.  if we add a nullpointercheck, users can associate an action with the timer that fills in the dueDate programmatically.
> in org.jbpm.scheduler.def.CreateTimerAction a nullpointercheck should be added to the following two lines in the createTimer method :
>     Duration duration = new Duration(dueDate);
>     Date dueDate = businessCalendar.add( new Date(), duration );

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:36:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:36:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPM-434) Transitionname
 should be used even if there is just one
Message-ID: <5068964.1159169761724.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-434?page=all ]

Tom Baeyens reassigned JBPM-434:
--------------------------------

    Assignee: Koen Aers  (was: Ronald van Kuijk)

This could be part of the first default proposal that is shown when generating a task form.

> Transitionname should be used even if there is just one
> -------------------------------------------------------
>
>                 Key: JBPM-434
>                 URL: http://jira.jboss.com/jira/browse/JBPM-434
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Web Interface
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>            Priority: Optional
>             Fix For: jBPM 3.2 alpha 1
>
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> By default a 'save and close' is shown. Besides i18n this, I think by default the chosen transitionname should be used (maybe unless it is tr1 ;-) )

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:39:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-434) Transitionname should
 be used even if there is just one
Message-ID: <21690368.1159169941180.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-434?page=all ]

Tom Baeyens updated JBPM-434:
-----------------------------

    Component/s: Graphical Process Designer
                     (was: Web Interface)

> Transitionname should be used even if there is just one
> -------------------------------------------------------
>
>                 Key: JBPM-434
>                 URL: http://jira.jboss.com/jira/browse/JBPM-434
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Graphical Process Designer
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>            Priority: Optional
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> By default a 'save and close' is shown. Besides i18n this, I think by default the chosen transitionname should be used (maybe unless it is tr1 ;-) )

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 03:39:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Mon, 25 Sep 2006 03:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPM-434) Transitionname should
 be used even if there is just one
Message-ID: <2450615.1159169941365.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPM-434?page=all ]

Tom Baeyens updated JBPM-434:
-----------------------------

    Fix Version/s:     (was: jBPM 3.2 alpha 1)

> Transitionname should be used even if there is just one
> -------------------------------------------------------
>
>                 Key: JBPM-434
>                 URL: http://jira.jboss.com/jira/browse/JBPM-434
>             Project: JBoss jBPM
>          Issue Type: Feature Request
>          Components: Graphical Process Designer
>            Reporter: Ronald van Kuijk
>         Assigned To: Koen Aers
>            Priority: Optional
>   Original Estimate: 5 minutes
>  Remaining Estimate: 5 minutes
>
> By default a 'save and close' is shown. Besides i18n this, I think by default the chosen transitionname should be used (maybe unless it is tr1 ;-) )

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:04:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3612) failing
 org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
In-Reply-To: <23206066.1157137423945.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19848006.1159171441631.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3612?page=all ]

Dimitris Andreadis updated JBAS-3612:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase
> ----------------------------------------------------------------------
>
>                 Key: JBAS-3612
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3612
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> test402Compatibility Failure
> Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.proxy.ClientContainerEx, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.proxy.ClientContainerEx,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub
> 	at org.jboss.test.compatibility.test.SerialVersionUIDUnitTestCase.test402Compatibility(SerialVersionUIDUnitTestCase.java:117)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>  test401Compatibility Failure Failures on SerialVersionComparisson:javax.management.loading.MLet, org.jboss.aspects.versioned.StateManager, org.jboss.console.manager.PluginManager$1, org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset, org.jboss.console.plugins.helpers.BasePluginWrapper, org.jboss.console.plugins.helpers.servlet.TabTag, org.jboss.console.remote.InvokerServlet, org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor, org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator, org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator, org.jboss.invocation.jrmp.server.JRMPInvoker, org.jboss.monitor.alarm.AlarmNotification, org.jboss.monitor.alarm.AlarmTableNotification, org.jboss.proxy.ejb.DynamicIIOPStub, org.jboss.proxy.ejb.HomeHandleImplIIOP, org.jboss.tm.iiop._CoordinatorExtStub, org.jboss.tm.iiop._TransactionFactoryExtStub, org.jboss.tm.iiop._TransactionServiceStub
> junit.framework.AssertionFailedError: Failures on SerialVersionComparisson:javax.management.loading.MLet,
> org.jboss.aspects.versioned.StateManager,
> org.jboss.console.manager.PluginManager$1,
> org.jboss.console.manager.interfaces.impl.GraphMBeanAttributeAction$MBeanXYDataset,
> org.jboss.console.plugins.helpers.BasePluginWrapper,
> org.jboss.console.plugins.helpers.servlet.TabTag,
> org.jboss.console.remote.InvokerServlet,
> org.jboss.ejb.plugins.inflow.MessageEndpointInterceptor,
> org.jboss.invocation.iiop.IIOPInvoker$PersistentServantLocator,
> org.jboss.invocation.iiop.IIOPInvoker$TransientServantLocator,
> org.jboss.invocation.jrmp.server.JRMPInvoker,
> org.jboss.monitor.alarm.AlarmNotification,
> org.jboss.monitor.alarm.AlarmTableNotification,
> org.jboss.proxy.ejb.DynamicIIOPStub,
> org.jboss.proxy.ejb.HomeHandleImplIIOP,
> org.jboss.tm.iiop._CoordinatorExtStub,
> org.jboss.tm.iiop._TransactionFactoryExtStub,
> org.jboss.tm.iiop._TransactionServiceStub

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:06:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3613) failing test in
 org.jboss.test.iiop.test.ParameterPassingStressTestCase
In-Reply-To: <18562400.1157137544244.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9710669.1159171561606.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3613?page=all ]

Dimitris Andreadis updated JBAS-3613:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing test in org.jboss.test.iiop.test.ParameterPassingStressTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3613
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3613
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Francisco Reverbel
>             Fix For: JBossAS-4.0.6.CR1
>
>
> test_getException Error
> Invalid indirection to offset 1704
> java.io.IOException: Invalid indirection to offset 1704
> 	at com.sun.corba.se.impl.io.IIOPInputStream$ActiveRecursionManager.getObject(IIOPInputStream.java:2684)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2218)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
> 	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
> 	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
> 	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
> 	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.read_Array(ValueHandlerImpl.java:756)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:325)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
> 	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
> 	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
> 	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
> 	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2438)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputObjectField(IIOPInputStream.java:1989)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputClassFields(IIOPInputStream.java:2213)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.inputObject(IIOPInputStream.java:1221)
> 	at com.sun.corba.se.impl.io.IIOPInputStream.simpleReadObject(IIOPInputStream.java:400)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValueInternal(ValueHandlerImpl.java:327)
> 	at com.sun.corba.se.impl.io.ValueHandlerImpl.readValue(ValueHandlerImpl.java:293)
> 	at org.jacorb.util.ValueHandler.readValue(ValueHandler.java:25)
> 	at org.jacorb.orb.CDRInputStream.read_untyped_value(CDRInputStream.java:2695)
> 	at org.jacorb.orb.CDRInputStream.read_typed_value(CDRInputStream.java:2753)
> 	at org.jacorb.orb.CDRInputStream.read_value(CDRInputStream.java:2310)
> 	at org.jacorb.orb.Any.read_value(Any.java:816)
> 	at org.jacorb.orb.CDRInputStream.read_any(CDRInputStream.java:673)
> 	at com.sun.corba.se.impl.javax.rmi.CORBA.Util.readAny(Util.java:401)
> 	at javax.rmi.CORBA.Util.readAny(Util.java:92)
> 	at org.jboss.iiop.rmi.marshal.CDRStream$ObjectReader.read(CDRStream.java:618)
> 	at org.jboss.iiop.rmi.marshal.strategy.StubStrategy.readRetval(StubStrategy.java:226)
> 	at org.jboss.proxy.ejb.DynamicIIOPStub.invoke(DynamicIIOPStub.java:128)
> 	at org.jboss.test.iiop.interfaces._StatelessSession_Stub.getException(Unknown Source)
> 	at org.jboss.test.iiop.test.ParameterPassingStressTestCase.test_getException(ParameterPassingStressTestCase.java:355)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:06:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3614) failing
 org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
In-Reply-To: <5797013.1157137545169.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8230784.1159171561727.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3614?page=all ]

Dimitris Andreadis updated JBAS-3614:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3614
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3614
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testRMMResourceImplementsMBean Failure
> testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> junit.framework.AssertionFailedError: testRMMResourceImplementsMBean: javax.management.MBeanException: Operation setpojoAttribute not in ModelMBeanInfo
> 	at org.jboss.test.jbossmx.compliance.modelmbean.ModelMBeanTestCase.testRMMResourceImplementsMBean(ModelMBeanTestCase.java:150)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3615) failing test in
 org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
In-Reply-To: <10850104.1157137663981.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25104801.1159171741414.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3615?page=all ]

Dimitris Andreadis updated JBAS-3615:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing test in org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase
> ------------------------------------------------------------------------------
>
>                 Key: JBAS-3615
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3615
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMX, Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testMalformed Failure
> invalid object name: domain:=,foo=bar
> junit.framework.AssertionFailedError: invalid object name: domain:=,foo=bar
> 	at org.jboss.test.jbossmx.compliance.objectname.MalformedTestCase$FullNameTEST.testMalformed(MalformedTestCase.java:152)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3616) failing test
 org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
In-Reply-To: <29398985.1157137784152.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28380281.1159171741532.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3616?page=all ]

Dimitris Andreadis updated JBAS-3616:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> failing test org.jboss.test.jmx.test.RMIAdaptorUnitTestCase
> -----------------------------------------------------------
>
>                 Key: JBAS-3616
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3616
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testMBeanInfoMarshalling Failure
> Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
> junit.framework.AssertionFailedError: Failed to get MBeanInfo for bean named: jboss.deployment:type=DeploymentScanner,flavor=URL
> 	at org.jboss.test.jmx.test.RMIAdaptorUnitTestCase.testMBeanInfoMarshalling(RMIAdaptorUnitTestCase.java:72)
>  

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3617) 3 failing tests in
 org.jboss.test.util.test.PropertyEditorsUnitTestCase
In-Reply-To: <15495472.1157137904044.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7869347.1159171741644.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3617?page=all ]

Dimitris Andreadis updated JBAS-3617:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

> 3 failing tests in org.jboss.test.util.test.PropertyEditorsUnitTestCase
> -----------------------------------------------------------------------
>
>                 Key: JBAS-3617
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3617
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.5.0_05 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Server VM 
> Java VM Version 1.5.0_05-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> testEditorSearchPath Failure
> Found org.jboss.util.propertyeditor in search path
> junit.framework.AssertionFailedError: Found org.jboss.util.propertyeditor in search path
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testEditorSearchPath(PropertyEditorsUnitTestCase.java:127)
> testJavaLangEditors Failure
> Found property editor for: class java.lang.Boolean
> junit.framework.AssertionFailedError: Found property editor for: class java.lang.Boolean
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJavaLangEditors(PropertyEditorsUnitTestCase.java:188)
> testJBossEditors Failure
> Found property editor for: class javax.management.ObjectName
> junit.framework.AssertionFailedError: Found property editor for: class javax.management.ObjectName
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.doTests(PropertyEditorsUnitTestCase.java:403)
> 	at org.jboss.test.util.test.PropertyEditorsUnitTestCase.testJBossEditors(PropertyEditorsUnitTestCase.java:306)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 04:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3611) Get the
 jboss-4.0-testsuite-sun-1.5 passing
In-Reply-To: <20914255.1157137303968.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8221991.1159171741765.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3611?page=all ]

Dimitris Andreadis updated JBAS-3611:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Fix the sun 1.5 testsuite in the next release. Focus on the sun/bea 1.4 testsuite runs and the OOMEs for the 4.0.5.GA release.

> Get the jboss-4.0-testsuite-sun-1.5 passing
> -------------------------------------------
>
>                 Key: JBAS-3611
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3611
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Container task for sun jdk1.5 test run failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:21:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Mon, 25 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3691) NoClassDefFoundError
 performing remote lookup of dynamic proxy using IBM JDK
Message-ID: <13932567.1159172461130.JavaMail.jira@cloud.prod.atl2.jboss.com>

NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK
----------------------------------------------------------------------------

                 Key: JBAS-3691
                 URL: http://jira.jboss.com/jira/browse/JBAS-3691
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.4.GA
         Environment: IBM JDK 1.5 32bit and 64bit
IBM JDK 1.4 64bit
            Reporter: Darran Lofthouse
         Assigned To: Darran Lofthouse
             Fix For: JBossAS-4.0.6.CR1


Using the IBM JDKs listed in the environment, performing a remote lookup of a dynamic proxy from within JBoss cases a NoClassDefFoundError.



-- 
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

        


From jira-events at jboss.com  Mon Sep 25 04:21:01 2006
From: jira-events at jboss.com (Darran Lofthouse (JIRA))
Date: Mon, 25 Sep 2006 04:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3691) NoClassDefFoundError
 performing remote lookup of dynamic proxy using IBM JDK
In-Reply-To: <13932567.1159172461130.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25849834.1159172461251.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3691?page=all ]

Darran Lofthouse updated JBAS-3691:
-----------------------------------

    Component/s: ClassLoading

> NoClassDefFoundError performing remote lookup of dynamic proxy using IBM JDK
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-3691
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3691
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: IBM JDK 1.5 32bit and 64bit
> IBM JDK 1.4 64bit
>            Reporter: Darran Lofthouse
>         Assigned To: Darran Lofthouse
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Using the IBM JDKs listed in the environment, performing a remote lookup of a dynamic proxy from within JBoss cases a NoClassDefFoundError.

-- 
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

        


From c14 at fullmailmarket.com  Mon Sep 25 04:57:54 2006
From: c14 at fullmailmarket.com (Carrier 179)
Date: Mon, 25 Sep 2006 04:57:54 -0400
Subject: [jboss-jira] =?iso-8859-1?q?Compare_y_se_convencer=E1!_?=
Message-ID: <200609250857.k8P8vtr8013790@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060925/8fa468dc/attachment-0001.html 

From jira-events at jboss.com  Mon Sep 25 05:27:35 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 05:27:35 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-80) consistent naming
	for jars
Message-ID: <22630014.1159176455961.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-80?page=comments#action_12343923 ] 
            
Kevin Conner commented on JBTM-80:
----------------------------------

In that case it should be the others as jbossts-common is shared between jts and jta and should not be named after either of them.

A better shceme would be to change the others to the following

jbossts-jta.jar
jbossts-jta-integration.jar
jbossts-jts.jar
jbossts-jts-integration.jar
jbossts-jts-jacorb.jar


> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 05:33:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 25 Sep 2006 05:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-80) consistent naming
	for jars
Message-ID: <29350056.1159176781089.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-80?page=comments#action_12343924 ] 
            
Mark Little commented on JBTM-80:
---------------------------------

Sure that's fine: it's consistent ;-)

> consistent naming for jars
> --------------------------
>
>                 Key: JBTM-80
>                 URL: http://jira.jboss.com/jira/browse/JBTM-80
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.4
>
>
> It's either jbossjts as the base name for jars, or jbossts, but not both. So we need to either change jbossts-common.jar or the others.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:06:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3597) Test error
 org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
In-Reply-To: <10564290.1157126863988.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7338944.1159178761203.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3597?page=comments#action_12343928 ] 
            
Dimitris Andreadis commented on JBAS-3597:
------------------------------------------

Client
3.2.8.SP1

> Test error org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-3597
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3597
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Test Suite
>         Environment: Java Version 1.4.2_09 
> Java Vendor Sun Microsystems Inc. 
> Java VM Name Java HotSpot(TM) Client VM 
> Java VM Version 1.4.2_09-b05 
> Java VM Info mixed mode 
> OS Name Linux 
> OS Version 2.6.9-34.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Test org.jboss.test.jbossmq.test.JBossMQUnitTest::testTopicSelectorChange fails with
> Error The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> javax.jms.IllegalStateException: The durable subscription is already in use. DurableSubscription[clientId=DurableSubscriberExample name=test selector=Value = 'A']
> 	at org.jboss.mq.server.JMSTopic.addSubscriber(JMSTopic.java:92)
> 	at org.jboss.mq.server.ClientConsumer.addSubscription(ClientConsumer.java:142)
> 	at org.jboss.mq.server.JMSDestinationManager.subscribe(JMSDestinationManager.java:541)
> 	at org.jboss.mq.server.JMSServerInterceptorSupport.subscribe(JMSServerInterceptorSupport.java:312)
> 	at org.jboss.mq.security.ServerSecurityInterceptor.subscribe(ServerSecurityInterceptor.java:157)
> 	at org.jboss.mq.server.TracingInterceptor.subscribe(TracingInterceptor.java:784)
> 	at org.jboss.mq.server.JMSServerInvoker.subscribe(JMSServerInvoker.java:312)
> 	at org.jboss.mq.il.uil2.ServerSocketManagerHandler.handleMsg(ServerSocketManagerHandler.java:182)
> 	at org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMsg(SocketManager.java:396)
> 	at org.jboss.mq.il.uil2.msgs.BaseMsg.run(BaseMsg.java:392)
> 	at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:748)
> 	at java.lang.Thread.run(Thread.java:534)
> For
> MatrixTestContainer(jms_4_0_4_GA)
> MatrixTestContainer(jms_4_0_x) 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.6.CR1
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13592026.1159178941201.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis updated JBAS-3437:
-------------------------------------

          Summary: Get the 3.2-compatibility tests passing for 4.0.6.CR1  (was: Get the 3.2-compatibility tests passing for 4.0.5.GA)
    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

There is no intention to fix the transient failures in the subtask for 4.0.5.GA

> Get the 3.2-compatibility tests passing for 4.0.6.CR1
> -----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:09:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3437) Get the
 3.2-compatibility tests passing for 4.0.6.CR1
In-Reply-To: <14781645.1153999451393.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13613903.1159178941328.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3437?page=all ]

Dimitris Andreadis reassigned JBAS-3437:
----------------------------------------

    Assignee:     (was: Dimitris Andreadis)

> Get the 3.2-compatibility tests passing for 4.0.6.CR1
> -----------------------------------------------------
>
>                 Key: JBAS-3437
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3437
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Task to hold compatibility test issues

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3228) Enable browsing of
 scheduled messages
Message-ID: <29941712.1159179301269.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3228?page=all ]

Adrian Brock closed JBAS-3228.
------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                   JBossAS-5.0.0.Beta
       Resolution: Done

See:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigQueue
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigTopic

> Enable browsing of scheduled messages
> -------------------------------------
>
>                 Key: JBAS-3228
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3228
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> We have a requirement to check the messages that are currently scheduled to deliver but not yet in the queue. 
> "ScheduledMessageCount" denotes the total number of scheduled messages. As far as I know, queue brower 
> only works with messages in the queue, so how to browse those scheduled messages? This is typically 
> more important than queued messages since they may be failed and reschduled ones. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3386) Expose "in process"
 messages via JMX
In-Reply-To: <33373175.1152715572226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27623785.1159179301463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3386?page=all ]

Adrian Brock closed JBAS-3386.
------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                   JBossAS-5.0.0.Beta
       Resolution: Done

See:

http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigQueue
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigTopic

> Expose "in process" messages via JMX
> ------------------------------------
>
>                 Key: JBAS-3386
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3386
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> Expose the number of "in process" (i.e. unacknowledged messages given to the client)
> via the JMX interfaces.
> e.g. change 
> org.jboss.mq.server.jmx.Queue to have
> public int getInProcessCount()
> {
>    return jmsQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.JMSQueue to have
> public int getInProcessCount()
> {
>    return basicQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.BasicQueue to have
> public int getInProcessCount()
> {
>    return unacknowledgeMessages.size(); 
> }

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:15:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3665) Update JBoss
 Serialization to 1.0.3.GA
In-Reply-To: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19187677.1159179301986.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3665?page=all ]

Dimitris Andreadis updated JBAS-3665:
-------------------------------------

    Summary: Update JBoss Serialization to 1.0.3.GA  (was: Update JBoss Serialization)

> Update JBoss Serialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBAS-3665
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3386) Expose "in process"
 messages via JMX
In-Reply-To: <33373175.1152715572226.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11516209.1159179302114.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3386?page=all ]

Adrian Brock reassigned JBAS-3386:
----------------------------------

    Assignee: Adrian Brock

> Expose "in process" messages via JMX
> ------------------------------------
>
>                 Key: JBAS-3386
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3386
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Expose the number of "in process" (i.e. unacknowledged messages given to the client)
> via the JMX interfaces.
> e.g. change 
> org.jboss.mq.server.jmx.Queue to have
> public int getInProcessCount()
> {
>    return jmsQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.JMSQueue to have
> public int getInProcessCount()
> {
>    return basicQueue.getInProcessCount(); 
> }
> org.jboss.mq.server.BasicQueue to have
> public int getInProcessCount()
> {
>    return unacknowledgeMessages.size(); 
> }

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:15:02 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 06:15:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3228) Enable browsing of
 scheduled messages
Message-ID: <20795662.1159179302287.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3228?page=all ]

Adrian Brock reassigned JBAS-3228:
----------------------------------

    Assignee: Adrian Brock

> Enable browsing of scheduled messages
> -------------------------------------
>
>                 Key: JBAS-3228
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3228
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> We have a requirement to check the messages that are currently scheduled to deliver but not yet in the queue. 
> "ScheduledMessageCount" denotes the total number of scheduled messages. As far as I know, queue brower 
> only works with messages in the queue, so how to browse those scheduled messages? This is typically 
> more important than queued messages since they may be failed and reschduled ones. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:24:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3582) Get the ejb3-4.0
 testsuite passing
In-Reply-To: <28677268.1156859718767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12611351.1159179841341.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3582?page=all ]

Dimitris Andreadis updated JBAS-3582:
-------------------------------------

    Comment: was deleted

> Get the ejb3-4.0 testsuite passing
> ----------------------------------
>
>                 Key: JBAS-3582
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3582
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> There are currenlty 28 failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:24:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:24:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3582) Get the ejb3-4.0
 testsuite passing
In-Reply-To: <28677268.1156859718767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20378073.1159179841520.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3582?page=comments#action_12343935 ] 
            
Dimitris Andreadis commented on JBAS-3582:
------------------------------------------

We are at a constant 22 erros failing:

http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite

If you do not intend to work on those failures this week, please reschedule for the next release.

> Get the ejb3-4.0 testsuite passing
> ----------------------------------
>
>                 Key: JBAS-3582
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3582
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.5.GA
>
>
> There are currenlty 28 failures

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-127) UID must befine a
 value for the
 maximum UID and enforce the ordering during comparison.
In-Reply-To: <29055818.1158767639193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30215329.1159180021351.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-127?page=all ]

Kevin Conner closed JBTM-127.
-----------------------------


> UID must befine a value for the maximum UID and enforce the ordering during comparison.
> ---------------------------------------------------------------------------------------
>
>                 Key: JBTM-127
>                 URL: http://jira.jboss.com/jira/browse/JBTM-127
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The UID 0:0:0:1 is a special case used to identify a last resource taking part in LRCO.  At present UID does not guarantee that this (or any) UID will always be greater then the others.
> UID must introduce the notion of a maximum UID, with guaranteed ordering during comparisons, which can be used by resources in LRCO.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-126) JTS XATerminator
 references arjunacore classes
In-Reply-To: <28668514.1158766021203.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27659863.1159180021477.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-126?page=all ]

Kevin Conner closed JBTM-126.
-----------------------------


> JTS XATerminator references arjunacore classes
> ----------------------------------------------
>
>                 Key: JBTM-126
>                 URL: http://jira.jboss.com/jira/browse/JBTM-126
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>         Environment: The JTS XATerminator references the classes in arjunacore instead of jts.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-125) The transaction manager
 implementation in JNDI should implement the
 org.jboss.tm.TransactionTimeoutConfiguration interface
In-Reply-To: <2335391.1158765841074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19364528.1159180021593.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-125?page=all ]

Kevin Conner closed JBTM-125.
-----------------------------


> The transaction manager implementation in JNDI should implement the org.jboss.tm.TransactionTimeoutConfiguration interface
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-125
>                 URL: http://jira.jboss.com/jira/browse/JBTM-125
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The jta/jts transaction manager delegates should provide an implementation of the TransactionTimeoutConfiguration interface.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-124) atsintegration must
 have its own logging
In-Reply-To: <5554493.1158765421327.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30581435.1159180021714.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-124?page=all ]

Kevin Conner closed JBTM-124.
-----------------------------


> atsintegration must have its own logging
> ----------------------------------------
>
>                 Key: JBTM-124
>                 URL: http://jira.jboss.com/jira/browse/JBTM-124
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2.1
>         Environment: The atsintegration contains internationalised logging but does not have a logging class.  The associated resource file is not generated by the build.
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-84) The Xid implementation
 should implement the hashCode and equals methods from Object
Message-ID: <21576829.1159180021869.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-84?page=all ]

Kevin Conner closed JBTM-84.
----------------------------


> The Xid implementation should implement the hashCode and equals methods from Object
> -----------------------------------------------------------------------------------
>
>                 Key: JBTM-84
>                 URL: http://jira.jboss.com/jira/browse/JBTM-84
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> XidImpl does not implement the equals and hashCode methods.  This prevents Xid being used in hash maps/sets.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-83) Multiple recovery
 threads get initialised when embedded in the application server
Message-ID: <22518653.1159180022037.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-83?page=all ]

Kevin Conner closed JBTM-83.
----------------------------


> Multiple recovery threads get initialised when embedded in the application server
> ---------------------------------------------------------------------------------
>
>                 Key: JBTM-83
>                 URL: http://jira.jboss.com/jira/browse/JBTM-83
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>         Attachments: jbossjta-integration.jar, jbossjts-integration.jar
>
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>
> The TransactionManagerServiceMBean implementations initialise the recovery manager directly instead of using the singleton.  The result of this is that the recovery manager is initialised twice, when other code calls the singleton, and two recovery threads are subsequently created.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-78) JTA installation does
 not include the XARecoveryModule
Message-ID: <16335546.1159180022170.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-78?page=all ]

Kevin Conner closed JBTM-78.
----------------------------


> JTA installation does not include the XARecoveryModule
> ------------------------------------------------------
>
>                 Key: JBTM-78
>                 URL: http://jira.jboss.com/jira/browse/JBTM-78
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The properrties file included in the JTA distribution does not include the XARecoveryModule

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:27:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:27:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-67) The installation notes
 incorrectly specify the initialisation of both TS interceptors.
Message-ID: <33012373.1159180022314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-67?page=all ]

Kevin Conner closed JBTM-67.
----------------------------


> The installation notes incorrectly specify the initialisation of both TS interceptors.
> --------------------------------------------------------------------------------------
>
>                 Key: JBTM-67
>                 URL: http://jira.jboss.com/jira/browse/JBTM-67
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.2
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>          Time Spent: 1 day, 6 hours
>  Remaining Estimate: 0 minutes
>
> The installation notes incorrectly specify the initialisation of both the standard context interceptor and the interposition interceptor.  These interceptors are mutually exclusive.
> The symptom exhibited by this problem is OutOfMemoryErrors being logged to the standard output.  This occurs because the interposition interceptor incorrectly interprets part of a text string as a length (approx 1GB).

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:30:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:30:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <7289705.1159180201279.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-87?page=comments#action_12343936 ] 
            
Kevin Conner commented on JBTM-87:
----------------------------------

The LRCO functionality has been added back in revision 6409

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:42:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 06:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3665) Update JBoss
 Serialization to 1.0.3.GA
In-Reply-To: <23592295.1158586801213.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28972585.1159180921382.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3665?page=all ]

Dimitris Andreadis closed JBAS-3665.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis  (was: Clebert Suconic)

Updated build-thirdparty.xml, seems ok.

> Update JBoss Serialization to 1.0.3.GA
> --------------------------------------
>
>                 Key: JBAS-3665
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3665
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> There is a bug parsing Big Strings (between 30k and 64k bytes) on JBoss Serialization that I would like to have it fixed before a new release.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:42:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <2529709.1159180921602.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-87?page=all ]

Kevin Conner resolved JBTM-87.
------------------------------

    Fix Version/s: 4.2.2
       Resolution: Done

> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:42:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-87) Put back LRCO JTA
	interface
Message-ID: <16085138.1159180921776.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-87?page=all ]

Kevin Conner closed JBTM-87.
----------------------------


> Put back LRCO JTA interface
> ---------------------------
>
>                 Key: JBTM-87
>                 URL: http://jira.jboss.com/jira/browse/JBTM-87
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>
> The last resource commit optimisation for JTA is missing the JTA marker interface, which was removed during the move from Arjuna to JBoss. We should be able to add this back now.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:48:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:48:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12922252.1159181281980.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-116?page=comments#action_12343938 ] 
            
Kevin Conner commented on JBTM-116:
-----------------------------------

Fixed in revision 6410


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:48:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12324595.1159181282174.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-116?page=all ]

Kevin Conner resolved JBTM-116.
-------------------------------

    Resolution: Done

> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:48:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:48:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-116) setting of default
 timeout logic broken in mbean
In-Reply-To: <24911061.1154943612074.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13800503.1159181282340.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-116?page=all ]

Kevin Conner closed JBTM-116.
-----------------------------


> setting of default timeout logic broken in mbean
> ------------------------------------------------
>
>                 Key: JBTM-116
>                 URL: http://jira.jboss.com/jira/browse/JBTM-116
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The mbean code for setting the default timeout says:
> public void setTransactionTimeout(int timeout) throws javax.transaction.SystemException
>     {
>         if (timeout > 0)
>         {
>             TxControl.setDefaultTimeout(timeout);
>         }
>         else
>             throw new javax.transaction.SystemException("Transaction Timeout < 0");
>     }
> This means that it's not possible for anyone to provide a value of -1, which means: transactions never timeout. Also, the if clause should say >= 0 if the else clause is to be accurate.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:54:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-81) Delay start of
	recovery manager
Message-ID: <26185830.1159181641393.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-81?page=all ]

Kevin Conner resolved JBTM-81.
------------------------------

    Resolution: Done

Fixed in revision 6408

> Delay start of recovery manager
> -------------------------------
>
>                 Key: JBTM-81
>                 URL: http://jira.jboss.com/jira/browse/JBTM-81
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace:
> 10:52:35,529 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\
> l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource
> java.io.StreamCorruptedException: unexpected end of block data
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\
> Module.java:178)
> This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 06:54:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 06:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-81) Delay start of recovery
	manager
Message-ID: <17085093.1159181641563.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-81?page=all ]

Kevin Conner closed JBTM-81.
----------------------------


> Delay start of recovery manager
> -------------------------------
>
>                 Key: JBTM-81
>                 URL: http://jira.jboss.com/jira/browse/JBTM-81
>             Project: JBoss Transaction Manager
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Minor
>             Fix For: 4.2.2
>
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> Currently the Recovery Manager begins working as soon as JBossAS starts. When the local JTA implementation is used and there is a transaction to recover, we get the following stack trace:
> 10:52:35,529 WARN  [loggerI18N] [com.arjuna.ats.internal.jta.resources.arjunacore.restorestate] [com.arjuna.ats.interna\
> l.jta.resources.arjunacore.restorestate] Exception on attempting to restore XAResource
> java.io.StreamCorruptedException: unexpected end of block data
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1321)
>         at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
>         at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
>         at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
>         at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
>         at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
>         at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.restore_state(XAResourceRecord.java:879)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.restore_state(BasicAction.java:1410)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:711)
>         at com.arjuna.ats.arjuna.coordinator.BasicAction.activate(BasicAction.java:673)
>         at com.arjuna.ats.arjuna.recovery.RecoverAtomicAction.<init>(RecoverAtomicAction.java:60)
>         at com.arjuna.ats.internal.arjuna.recovery.AtomicActionRecoveryModule.doRecoverTransaction(AtomicActionRecovery\
> Module.java:178)
> This is because the rest of the system isn't yet fully initialised. The next periodic run of recovery does not suffer this problem and recovery completes successfully. We should look at delaying the start of the Recovery Manager until JBossAS is fully initialised.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:12:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-130) Validation of timeout
 values before calling the reaper
Message-ID: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>

Validation of timeout values before calling the reaper
------------------------------------------------------

                 Key: JBTM-130
                 URL: http://jira.jboss.com/jira/browse/JBTM-130
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:21:01 2006
From: jira-events at jboss.com (James Hickey (JIRA))
Date: Mon, 25 Sep 2006 07:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-784) "Random"
 TimeoutException occurs after CacheLoader get() returns
Message-ID: <5715269.1159183261505.JavaMail.jira@cloud.prod.atl2.jboss.com>

"Random" TimeoutException occurs after CacheLoader get() returns
----------------------------------------------------------------

                 Key: JBCACHE-784
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-784
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Cache loaders
    Affects Versions: 1.4.0
         Environment: JBCache 1.4.0GA working in REPL_ASYNC mode on multiple Weblogic 8.1 instances (pessimistic locking), no eviction policy
            Reporter: James Hickey
         Assigned To: Manik Surtani


We experience a strange issue which happens every so often whereby shortly after one of our replicated cache instances calls it's CacheLoader.get() to populate a particular FQN, a TimeoutException occurs - It is extremely difficult to reproduce but the scenario/stack trace follows:

The below exception is thrown 15 secs (configured timeout) AFTER the cache loader's get() method successfully returns (can see this as we have debugging in the cache loader). Subsequent calls are instantaneously successful and do not result in  a further call to the cacheloader.

It looks to me like it could possibly be some kind of tx/locking/thread contention issue, as it happens more often than not where we have approx 10-20 threads which have all resulted in a call to the cache loader in a short space of time.

Any advice/opinion would be appreciated

Thanks
James

org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/demandload/db/gps/ipb/security/sdm/840/SECNO/DB0028807589, calle
r=GlobalTransaction:<10.152.103.22:28680>:363, lock=write owner=GlobalTransaction:<10.152.103.22:28680>:362 (org.jboss.cache.lock.Lo
ckStrategyReadCommitted at 10e4fd3)
        at org.jboss.cache.Node.acquire(Node.java:407)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:231)
        at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:166)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheLoaderInterceptor.invoke(CacheLoaderInterceptor.java:197)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:34)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheStoreInterceptor.invoke(CacheStoreInterceptor.java:135)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:345)
        at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:156)
        at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
        at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:138)
        at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5535)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3485)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3466)
        at org.jboss.cache.TreeCache.get(TreeCache.java:3453)


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-130) Validation of
 timeout values before calling the reaper
In-Reply-To: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32126522.1159183981226.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-130?page=comments#action_12343943 ] 
            
Kevin Conner commented on JBTM-130:
-----------------------------------

Fixed in revision 6411.

> Validation of timeout values before calling the reaper
> ------------------------------------------------------
>
>                 Key: JBTM-130
>                 URL: http://jira.jboss.com/jira/browse/JBTM-130
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-130) Validation of
 timeout values before calling the reaper
In-Reply-To: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15880423.1159183981352.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-130?page=all ]

Kevin Conner resolved JBTM-130.
-------------------------------

    Resolution: Done

> Validation of timeout values before calling the reaper
> ------------------------------------------------------
>
>                 Key: JBTM-130
>                 URL: http://jira.jboss.com/jira/browse/JBTM-130
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20541291.1159183981805.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3651?page=all ]

Dimitris Andreadis reassigned JBAS-3651:
----------------------------------------

    Assignee: Ryan Campbell  (was: Dimitris Andreadis)

Ryan, could you assign this to somebody that would record testsuite failures on Solaris10?

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Ryan Campbell
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:33:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:33:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-130) Validation of timeout
 values before calling the reaper
In-Reply-To: <7831341.1159182721344.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23410919.1159183981918.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-130?page=all ]

Kevin Conner closed JBTM-130.
-----------------------------


> Validation of timeout values before calling the reaper
> ------------------------------------------------------
>
>                 Key: JBTM-130
>                 URL: http://jira.jboss.com/jira/browse/JBTM-130
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> There are a number of places which allow invalid values to be passed to the transaction reaper.  We need to review all paths through to the reaper and tidy these up.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-131) XidImple requires
	serialVersionUID
Message-ID: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>

XidImple requires serialVersionUID
----------------------------------

                 Key: JBTM-131
                 URL: http://jira.jboss.com/jira/browse/JBTM-131
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Kevin Conner
         Assigned To: Mark Little


The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-131) XidImple requires
 serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13520682.1159184341601.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-131?page=all ]

Kevin Conner reassigned JBTM-131:
---------------------------------

    Assignee: Kevin Conner  (was: Mark Little)

> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-131) XidImple requires
 serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10623317.1159184342135.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-131?page=comments#action_12343945 ] 
            
Kevin Conner commented on JBTM-131:
-----------------------------------

Fixed in revision 6412.

> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:39:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:39:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-131) XidImple requires
 serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1380500.1159184342264.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-131?page=all ]

Kevin Conner resolved JBTM-131.
-------------------------------

    Resolution: Done

> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:42:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 07:42:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-131) XidImple requires
	serialVersionUID
In-Reply-To: <19103714.1159184341384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14391330.1159184521336.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-131?page=all ]

Kevin Conner closed JBTM-131.
-----------------------------


> XidImple requires serialVersionUID
> ----------------------------------
>
>                 Key: JBTM-131
>                 URL: http://jira.jboss.com/jira/browse/JBTM-131
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>
> The change for JBTM-84 changed the serialVersionUID for the Xid implementation.  The implementation needs to specify the serialVersionUID to allow for compatibility with the previous version.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:42:02 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 07:42:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3071) MemoryLeak
 (redeployment) on EJB3
Message-ID: <24708401.1159184522559.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ]

Dimitris Andreadis reassigned JBAS-3071:
----------------------------------------

    Assignee: Emmanuel Bernard  (was: Bill Burke)

> MemoryLeak (redeployment) on EJB3
> ---------------------------------
>
>                 Key: JBAS-3071
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Emmanuel Bernard
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> This might be caused by JBAS-3016:
> But I'm seeing this strong reference:
> org.jboss.mx.loading.UnifiedClassLoader3 at 33411906
> !--- org.jboss.ejb3.stateless.StatelessContainer at 29610827
> We should make sure EJB3 packages are not leaking.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 07:57:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 07:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3693) Other XAResource
	errors
Message-ID: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>

Other XAResource errors
-----------------------

                 Key: JBAS-3693
                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: JCA service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Adrian Brock
         Assigned To: Weston Price
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


Further to JBAS-3336 (resource manager error during error should close the connection). 

There are other xa resource failures that need to be catered for.
e.g. a failure to delist probably means a probably means a problem with the connection.

Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection

   public void end(Xid xid, int flags) throws XAException
   {
+      try
+      {
         xaResource.end(xid, flags);
+      }
+      catch (XAException e)
+      {
+          broadcastConnectionError(e);
+          throw e;
+      }
...


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 08:00:01 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Mon, 25 Sep 2006 08:00:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3676) Upgrade
 jboss-common to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7907674.1159185601239.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3676?page=comments#action_12343946 ] 
            
Thomas Diesler commented on JBAS-3676:
--------------------------------------

What is the SVN branch for this? 
I need to check if my changes are going to make it in 4.0.5

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Mon Sep 25 08:03:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 08:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3676) Upgrade
 jboss-common to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15430107.1159185781042.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3676?page=comments#action_12343947 ] 
            
Dimitris Andreadis commented on JBAS-3676:
------------------------------------------

Hi Thomas, it's here:

https://svn.jboss.org/repos/common/common-old/branches/Branch_1_0/

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Mon Sep 25 08:06:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 08:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18143872.1159185961289.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3693?page=all ]

Adrian Brock updated JBAS-3693:
-------------------------------

    Description: 
Further to JBAS-3336 (resource manager error during enlist should close the connection). 

There are other xa resource failures that need to be catered for.
e.g. a failure to delist probably means a problem with the connection.

Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection

   public void end(Xid xid, int flags) throws XAException
   {
+      try
+      {
         xaResource.end(xid, flags);
+      }
+      catch (XAException e)
+      {
+          broadcastConnectionError(e);
+          throw e;
+      }
...


  was:
Further to JBAS-3336 (resource manager error during error should close the connection). 

There are other xa resource failures that need to be catered for.
e.g. a failure to delist probably means a probably means a problem with the connection.

Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection

   public void end(Xid xid, int flags) throws XAException
   {
+      try
+      {
         xaResource.end(xid, flags);
+      }
+      catch (XAException e)
+      {
+          broadcastConnectionError(e);
+          throw e;
+      }
...



> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 08:54:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Mon, 25 Sep 2006 08:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-148) Glossary of terms
Message-ID: <28492607.1159188841189.JavaMail.jira@cloud.prod.atl2.jboss.com>

Glossary of terms
-----------------

                 Key: JBESB-148
                 URL: http://jira.jboss.com/jira/browse/JBESB-148
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


We need a glossary of terms in the documentation and/or wiki.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:16:02 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:16:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-132) Incorrect Uid values
 used in JTA/JTS XAResourceRecord
Message-ID: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>

Incorrect Uid values used in JTA/JTS XAResourceRecord
-----------------------------------------------------

                 Key: JBTM-132
                 URL: http://jira.jboss.com/jira/browse/JBTM-132
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.

The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-132) Incorrect Uid
 values used in JTA/JTS XAResourceRecord
In-Reply-To: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16128490.1159190461138.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-132?page=comments#action_12343952 ] 
            
Kevin Conner commented on JBTM-132:
-----------------------------------

Fixed in revision 6414.

> Incorrect Uid values used in JTA/JTS XAResourceRecord
> -----------------------------------------------------
>
>                 Key: JBTM-132
>                 URL: http://jira.jboss.com/jira/browse/JBTM-132
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.
> The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-132) Incorrect Uid values
 used in JTA/JTS XAResourceRecord
In-Reply-To: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3310730.1159190461247.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-132?page=all ]

Kevin Conner resolved JBTM-132.
-------------------------------

    Resolution: Done

> Incorrect Uid values used in JTA/JTS XAResourceRecord
> -----------------------------------------------------
>
>                 Key: JBTM-132
>                 URL: http://jira.jboss.com/jira/browse/JBTM-132
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.
> The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:21:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Mon, 25 Sep 2006 09:21:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-132) Incorrect Uid values
 used in JTA/JTS XAResourceRecord
In-Reply-To: <26692659.1159190162034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12329627.1159190461396.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-132?page=all ]

Kevin Conner closed JBTM-132.
-----------------------------


> Incorrect Uid values used in JTA/JTS XAResourceRecord
> -----------------------------------------------------
>
>                 Key: JBTM-132
>                 URL: http://jira.jboss.com/jira/browse/JBTM-132
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Both versions of XAResourceRecord support an interface for indiciating that a resource should be the first or last to be called.  This is achieved by assigning a specific Uid to those resources but the one used for the first resource is incorrect.
> The values used by both is 0:0:0:1 which was never the lowest Uid.  These values should also be handled directly by the Uid class so that they can remain consistent.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:43:02 2006
From: jira-events at jboss.com (Emmanuel Bernard (JIRA))
Date: Mon, 25 Sep 2006 09:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3071) MemoryLeak
 (redeployment) on EJB3
Message-ID: <22232286.1159191782189.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ]

Emmanuel Bernard reassigned JBAS-3071:
--------------------------------------

    Assignee: Bill Burke  (was: Emmanuel Bernard)

I'm removing my assignment.
My part has been fixed but I see things on the Timer and the ThreadLocal, reassigning to Bill so that he can dispatch to someone else.

> MemoryLeak (redeployment) on EJB3
> ---------------------------------
>
>                 Key: JBAS-3071
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> This might be caused by JBAS-3016:
> But I'm seeing this strong reference:
> org.jboss.mx.loading.UnifiedClassLoader3 at 33411906
> !--- org.jboss.ejb3.stateless.StatelessContainer at 29610827
> We should make sure EJB3 packages are not leaking.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:45:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-127) Eliminate all GPL
 dependencies from the new forums
Message-ID: <17804893.1159191901022.JavaMail.jira@cloud.prod.atl2.jboss.com>

Eliminate all GPL dependencies from the new forums
--------------------------------------------------

                 Key: JBFORUMS-127
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-127
             Project: JBoss Forums
          Issue Type: Task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 1.1.0 Alpha


Need to identify any GPL dependencies and convert to LGPL

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:47:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-128) Need to remove
 the phpBB graphics with our own
Message-ID: <31271635.1159192021233.JavaMail.jira@cloud.prod.atl2.jboss.com>

Need to remove the phpBB graphics with our own
----------------------------------------------

                 Key: JBFORUMS-128
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-128
             Project: JBoss Forums
          Issue Type: Sub-task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: James Cobb
             Fix For: 1.1.0 Alpha




-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:47:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-128) Need to remove
 the phpBB graphics and replace with our own
In-Reply-To: <31271635.1159192021233.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15415731.1159192021390.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-128?page=all ]

Sohil Shah updated JBFORUMS-128:
--------------------------------

    Summary: Need to remove the phpBB graphics and replace with our own  (was: Need to remove the phpBB graphics with our own)

> Need to remove the phpBB graphics and replace with our own
> ----------------------------------------------------------
>
>                 Key: JBFORUMS-128
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-128
>             Project: JBoss Forums
>          Issue Type: Sub-task
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: James Cobb
>             Fix For: 1.1.0 Alpha
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:47:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:47:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-129) Modify the schema
 being used from PHPBB
Message-ID: <31925238.1159192021505.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modify the schema being used from PHPBB
---------------------------------------

                 Key: JBFORUMS-129
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-129
             Project: JBoss Forums
          Issue Type: Sub-task
            Reporter: Sohil Shah
         Assigned To: Sohil Shah




-- 
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

        


From jira-events at jboss.com  Mon Sep 25 09:50:01 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Mon, 25 Sep 2006 09:50:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-129) Modify the
 schema being used from PHPBB
In-Reply-To: <31925238.1159192021505.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31354938.1159192201598.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-129?page=comments#action_12343954 ] 
            
Sohil Shah commented on JBFORUMS-129:
-------------------------------------

Also make sure once the schema is modified,

corresponding changes are made in the Hibernate layer to accomodate the new schema. This should probably only require changing mapping files.


But will know more once the schema migration is started.


Also, test and make sure the Forums bussiness module plays nice with the new schema

> Modify the schema being used from PHPBB
> ---------------------------------------
>
>                 Key: JBFORUMS-129
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-129
>             Project: JBoss Forums
>          Issue Type: Sub-task
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 10:34:01 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Mon, 25 Sep 2006 10:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-329) Implement block() in
	Multiplexer
Message-ID: <31142280.1159194841184.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement block() in Multiplexer
--------------------------------

                 Key: JGRP-329
                 URL: http://jira.jboss.com/jira/browse/JGRP-329
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


Simple implementation: block all of the services on top of the same channel in the Multiplexer.

Does this potentially need a blockCompleted() callback ?

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 10:51:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 10:51:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22775771.1159195861332.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3693?page=comments#action_12343959 ] 
            
Weston Price commented on JBAS-3693:
------------------------------------

I should have done this before. I wondered about it. I'll get on it.

> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:00:02 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 11:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3183) Integration with
	WebSphere MQ 5.x
Message-ID: <12106327.1159196403003.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3183?page=all ]

Weston Price updated JBAS-3183:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Moving to 4.0.6

> Integration with WebSphere MQ 5.x
> ---------------------------------
>
>                 Key: JBAS-3183
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3183
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>         Environment: WebSphereMQ 5.3 with Extended TX client
>            Reporter: Luc Texier
>         Assigned To: Weston Price
>            Priority: Critical
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: mq-trace.jar, mq-xa.zip
>
>
> http://wiki.jboss.org/wiki/Wiki.jsp?page=UsingWebSphereMQSeriesWithJBossASPart2
> we need to make some changes to StdServerSession and StdServerSessionPool to integrate two workarounds in order to properly integrate with WSMQ 5.x and support their XA resource implementation and transaction handling

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:09:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 11:09:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14246618.1159196941530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3690?page=all ]

Brian Stansberry updated JBAS-3690:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
         Assignee: Brian Stansberry

*If* it's a bug I'll fix it for 4.0.5.GA.

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:12:01 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Mon, 25 Sep 2006 11:12:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3694) Activate MDB in a
	seperate thread
Message-ID: <1886851.1159197121304.JavaMail.jira@cloud.prod.atl2.jboss.com>

Activate MDB in a seperate thread
---------------------------------

                 Key: JBAS-3694
                 URL: http://jira.jboss.com/jira/browse/JBAS-3694
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JMS service
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock


There should be an option in the MDB startup (JMSContainerInvoker)
to activate the jms delivery on a separate thread such that a miss-behaving JMS
implementation does not block the main bootstrap thread.

This already exists in the new jms resource adapter inflow
where the connection to the jms server is executed via the work manager. 

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:18:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 11:18:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1434) JMS Message Inflow
Message-ID: <24339542.1159197481936.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1434?page=all ]

Weston Price updated JBAS-1434:
-------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Being done in tandem with 3183. 

> JMS Message Inflow
> ------------------
>
>                 Key: JBAS-1434
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1434
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.2 Final
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-4.0.6.CR1
>
>
> Forums Discussion Thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=48672
> The JMS message inflow in the JMS resource adapter needs properly testing.
> There are basic tests, but the following are missing:
> 1) Complete tests of edge cases for each configuration parameter in the activation spec
> 2) Failure tests to confirm the implementation handles error gracefully
> 3) Stress tests to make sure there the implementation is stable
> 4) Performance tests to optimize the implementation
> Additionally, we need to confirm that it is possible to use this implementation for EJB2.0
> style deployments and hence as the default configuration. 
> This should be possible provided the user has not created their own
> container configuration that uses the old JMSContainerInvoker explicitly.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:27:06 2006
From: jira-events at jboss.com (Jason T. Greene (JIRA))
Date: Mon, 25 Sep 2006 11:27:06 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14342829.1159198026311.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3678?page=all ]

Jason T. Greene reassigned JBAS-3678:
-------------------------------------

    Assignee: Ryan Campbell  (was: Jason T. Greene)

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Ryan Campbell
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:45:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-76) optimize unmarshalling
 of arrays of repeatable particles
In-Reply-To: <14684322.1154703492098.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22048116.1159199101540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-76?page=all ]

Alexey Loubyansky closed JBXB-76.
---------------------------------

    Fix Version/s: JBossXB-1.0.0.CR7
                       (was: JBossXB-1.0)
       Resolution: Done

Fixed.

> optimize unmarshalling of arrays of repeatable particles
> --------------------------------------------------------
>
>                 Key: JBXB-76
>                 URL: http://jira.jboss.com/jira/browse/JBXB-76
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>
> When an repeatable XSD term (element, model group or wildcard) is bound to a field of an array type, the current implementation acts inefficient.
> Each time the term is unmarshalled, the array which is the value of the field is recreated to add the just unmarshalled particle. Instead, repeatable terms should be recognized, the array items should be collected in a temp collection and the final array should be created when the last repeated term is unmarshalled.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:45:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-85) Add support for base64
 simple type bean properties to be XOP optimized
In-Reply-To: <24462351.1158682256992.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16201814.1159199101740.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-85?page=all ]

Alexey Loubyansky closed JBXB-85.
---------------------------------

    Fix Version/s: JBossXB-1.0.0.CR7
       Resolution: Done

Fixed.

> Add support for base64 simple type bean properties to be XOP optimized
> ----------------------------------------------------------------------
>
>                 Key: JBXB-85
>                 URL: http://jira.jboss.com/jira/browse/JBXB-85
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>
> Currently this only works with complex types. In order to be interoperable with MSFT we need to support this. Take a look at the following schema:
> <xs:element name="EchoBinaryAsString">
> 	<xs:complexType>
> 	<xs:sequence>
> <xs:element minOccurs="0" name="array" nillable="true" type="xs:base64Binary"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> The type xs:base64Binary needs be optimized by jbossxb.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:45:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 11:45:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29497678.1159199101869.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3659?page=comments#action_12343967 ] 
            
Brian Stansberry commented on JBAS-3659:
----------------------------------------

I would doubt it.  This should result in an increase of about 2.3MB in memory used by the process (not heap memory; this is memory used by the underlying TCP subsystem.  Not sure what the problems you're seeing are; will respond separately to try to trace it down.

> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:54:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 11:54:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-37) Remove dependency on
 ObjectModelProvider in SchemaBinding-based marshaller
Message-ID: <20459759.1159199641361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-37?page=all ]

Alexey Loubyansky closed JBXB-37.
---------------------------------

    Resolution: Out of Date

It doesn't actually use it. But references in method signatures for historical reasons.

> Remove dependency on ObjectModelProvider in SchemaBinding-based marshaller
> --------------------------------------------------------------------------
>
>                 Key: JBXB-37
>                 URL: http://jira.jboss.com/jira/browse/JBXB-37
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Feature Request
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>
> This marshaller should use binding metadata available in the SchemaBinding.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 11:57:01 2006
From: jira-events at jboss.com (jasonc411 (JIRA))
Date: Mon, 25 Sep 2006 11:57:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-503) Compiler Throwing
 an exception on generics
Message-ID: <23708343.1159199821228.JavaMail.jira@cloud.prod.atl2.jboss.com>

Compiler Throwing an exception on generics
------------------------------------------

                 Key: JBRULES-503
                 URL: http://jira.jboss.com/jira/browse/JBRULES-503
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions: 3.0.4
         Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
            Reporter: jasonc411
         Assigned To: Mark Proctor


#created on: Sep 15, 2006
package com.ca.data.dsrules

#list any import classes here.
import com.ca.data.model.base.DataSourceEnum;
import com.ca.data.model.issuer.Issuer;
import java.util.ArrayList;
import java.util.List;
import com.ca.data.model.Data;
import com.ca.data.datasubs.utils.JMSServiceLocator;
import com.ca.data.jms.JMSTextMessageSender;


function void save(Issuer issuer){
	JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
	Data data = new Data();
	List<Issuer> myIssuers = new ArrayList<Issuer>();
	myIssuers.add(issuer);
	
	Data.setIssuerList(myIssuers);
	
	cleanQueue.simpleSend(issuer);
}

rule "Persist Validated Data"
	agenda-group "Data In"
	no loop
	salience 1
	
	when
		issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
	then 
		System.out.println("Validated");
		save(issuer);
end

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:00:02 2006
From: jira-events at jboss.com (jasonc411 (JIRA))
Date: Mon, 25 Sep 2006 12:00:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-503) Compiler
 Throwing an exception on generics
In-Reply-To: <23708343.1159199821228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27009052.1159200002137.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-503?page=comments#action_12343970 ] 
            
jasonc411 commented on JBRULES-503:
-----------------------------------

When compiling the above file, I get the error:

2006-09-25 09:56:54,914 ERROR com.ca.data.controllers.issuer.PersistIssuer Unable to add processing rules, exception unspecified. 
org.drools.rule.InvalidRulePackage: Function Compilation error

        at org.drools.rule.Package.checkValidity(Unknown Source)
        at org.drools.common.AbstractRuleBase.addPackage(Unknown Source)


When I remove the line with the generic, it compiles fine.  Also there is no additional info other than exception unspecified.  

> Compiler Throwing an exception on generics
> ------------------------------------------
>
>                 Key: JBRULES-503
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-503
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.4
>         Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
>            Reporter: jasonc411
>         Assigned To: Mark Proctor
>
> #created on: Sep 15, 2006
> package com.ca.data.dsrules
> #list any import classes here.
> import com.ca.data.model.base.DataSourceEnum;
> import com.ca.data.model.issuer.Issuer;
> import java.util.ArrayList;
> import java.util.List;
> import com.ca.data.model.Data;
> import com.ca.data.datasubs.utils.JMSServiceLocator;
> import com.ca.data.jms.JMSTextMessageSender;
> function void save(Issuer issuer){
> 	JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
> 	Data data = new Data();
> 	List<Issuer> myIssuers = new ArrayList<Issuer>();
> 	myIssuers.add(issuer);
> 	
> 	Data.setIssuerList(myIssuers);
> 	
> 	cleanQueue.simpleSend(issuer);
> }
> rule "Persist Validated Data"
> 	agenda-group "Data In"
> 	no loop
> 	salience 1
> 	
> 	when
> 		issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
> 	then 
> 		System.out.println("Validated");
> 		save(issuer);
> end

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:03:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 12:03:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17800000.1159200181719.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3690?page=all ]

Brian Stansberry resolved JBAS-3690.
------------------------------------

    Fix Version/s:     (was: JBossAS-4.0.5.GA)
       Resolution: Rejected

The test is fine.  JSESSIONIDSSO is the name of the cookie used for SSO.

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:06:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 12:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9618480.1159200361497.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-79?page=all ]

Alexey Loubyansky updated JBXB-79:
----------------------------------

        Fix Version/s: JBossXB-1.0.0.CR7
    Affects Version/s: JBossXB-1.0.0.CR6

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:06:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Mon, 25 Sep 2006 12:06:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBXB-82) Release CR7 that
 aligns with AS 4.0.5.GA
In-Reply-To: <5411313.1158669716890.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25275032.1159200361672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-82?page=all ]

Alexey Loubyansky updated JBXB-82:
----------------------------------

    Fix Version/s: JBossXB-1.0.0.CR7

> Release CR7 that aligns with AS 4.0.5.GA
> ----------------------------------------
>
>                 Key: JBXB-82
>                 URL: http://jira.jboss.com/jira/browse/JBXB-82
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Task
>            Reporter: Heiko Braun
>         Assigned To: Alexey Loubyansky
>            Priority: Critical
>             Fix For: JBossXB-1.0.0.CR7
>
>
> JBossWS has a dependency on it.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:26:04 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:26:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3071) MemoryLeak
	(redeployment) on EJB3
Message-ID: <4298114.1159201564575.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3071?page=all ]

Dimitris Andreadis updated JBAS-3071:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

Rescheduling

> MemoryLeak (redeployment) on EJB3
> ---------------------------------
>
>                 Key: JBAS-3071
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3071
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB3
>    Affects Versions: JBossAS-4.0.4.CR2
>            Reporter: Clebert Suconic
>         Assigned To: Bill Burke
>            Priority: Critical
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
> This might be caused by JBAS-3016:
> But I'm seeing this strong reference:
> org.jboss.mx.loading.UnifiedClassLoader3 at 33411906
> !--- org.jboss.ejb3.stateless.StatelessContainer at 29610827
> We should make sure EJB3 packages are not leaking.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:37:01 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Mon, 25 Sep 2006 12:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1056) Drag/Drop
 dropmarker for better user experience
In-Reply-To: <14908268.1158947101578.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18925673.1159202221093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1056?page=all ]

Roy Russo resolved JBPORTAL-1056.
---------------------------------

    Resolution: Done

> Drag/Drop dropmarker for better user experience
> -----------------------------------------------
>
>                 Key: JBPORTAL-1056
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1056
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3111) JBOSS does not
 release handle of log files even when logging is complete
Message-ID: <1132563.1159202941220.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3111?page=all ]

Dimitris Andreadis closed JBAS-3111.
------------------------------------

    Resolution: Rejected

I don't think this is a jboss issue, maybe a log4j one. If the logger is configured to use org.jboss.logging.appender.DailyRollingFileAppender, doen't that let you remove the older/renamed logs?

> JBOSS does not release handle of log files even when logging is complete
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3111
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3111
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Logging
>         Environment: Windows 2000/xp, J2SDK1.4.2.08
>            Reporter: shishir das
>
> JBOSS does not release log file handle even when logging is complete. So we cannot delete log files no longer needed unless we restart the jboss server. To elaborate the scenario Consider the following:- 
>  
> Suppose there is an web application. one of its engines run 5 times a day and each run generates 10 log files. JBOSS is up for a year, it will contains 18000 odd open file handle which is not acceptable.
> JBOSS version 3.2.3

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:49:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2910) minor try-finally
 changes to make
 sure that some streams and JDBC objects are always closed
Message-ID: <18321687.1159202941423.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2910?page=all ]

Dimitris Andreadis updated JBAS-2910:
-------------------------------------

    Component/s: CMP service
                 Web (Tomcat) service

> minor try-finally changes to make sure that some streams and JDBC objects are always closed
> -------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2910
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2910
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, CMP service
>            Reporter: Westley Weimer
>            Priority: Minor
>   Original Estimate: 20 minutes
>  Remaining Estimate: 20 minutes
>
> Attached are minor candidate patches for jboss (against a CVS checkout of the sources on 2006 03 08) that ensure that resources are closed properly in some unlikely exceptional cases. These changse should not affect jboss functionality at all aside from ensuring that resources are closed in a few more cases. 
> This is hardly the most exciting sort of bugfix in the world, but jboss does seem to be concerned with leaks and being ironclad in these situations. The patches all have the general flavor of changing "open; work; close" to "try { open; work; } finally { close; }". It should take a knowledgeable dev at most a few minutes to eyeball them and accept or reject them. 
> I'm not sure how to attach the patch file, so I'm copying it here. My apologies if this is the wrong place for this sort of thing. 
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/CMPInMemoryPersistenceManager.java	2006-03-08 16:29:45.917109700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/CMPInMemoryPersistenceManager.java	2006-03-08 16:34:15.141058700 -0500
> @@ -355,11 +355,12 @@
>      */
>     public void loadEntity (EntityEnterpriseContext ctx)
>     {
> +      java.io.ObjectInputStream in = null;
>        try
>        {
>           // Read fields
>           
> -         java.io.ObjectInputStream in = new CMPObjectInputStream
> +         in = new CMPObjectInputStream
>              (new java.io.ByteArrayInputStream ((byte[])this.beans.get (ctx.getId ())));
>           
>           Object obj = ctx.getInstance ();
> @@ -370,12 +371,15 @@
>              f[i].set (obj, in.readObject ());
>           }
>           
> -         in.close ();
>        }
>        catch (Exception e)
>        {
>           throw new EJBException ("Load failed", e);
>        }
> +      finally
> +      {
> +        if (in != null) { try { in.close(); } catch (Exception e) { } }
> +      }
>     }
>     
>     /**
> --- jboss-20060308-orig/src/main/org/jboss/invocation/http/interfaces/Util.java	2006-03-08 16:29:47.899706700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/http/interfaces/Util.java	2006-03-08 17:32:40.259780600 -0500
> @@ -158,7 +158,9 @@
>        conn.setRequestProperty("ContentType", REQUEST_CONTENT_TYPE);
>        conn.setRequestMethod("POST");
>        OutputStream os = conn.getOutputStream();
> +      ObjectInputStream ois = null;
>        ObjectOutputStream oos = new ObjectOutputStream(os);
> +      try { 
>        try
>        {
>           oos.writeObject(mi);
> @@ -173,12 +175,14 @@
>  
>        // Get the response MarshalledValue object
>        InputStream is = conn.getInputStream();
> -      ObjectInputStream ois = new ObjectInputStream(is);
> +        ois = new ObjectInputStream(is);
>        MarshalledValue mv = (MarshalledValue) ois.readObject();
>        // A hack for jsse connection pooling (see patch ).
>        ois.read();
> -      ois.close();
> -      oos.close();
> +      } finally { 
> +        if (ois != null) { try { ois.close(); } catch (Exception e) { } } 
> +        if (oos != null) { try { oos.close(); } catch (Exception e) { } } 
> +      } 
>  
>        // If the encoded value is an exception throw it
>        Object value = mv.get();
> --- jboss-20060308-orig/src/main/org/jboss/invocation/MarshalledValue.java	2006-03-08 16:29:48.008983700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/MarshalledValue.java	2006-03-08 17:30:01.198298600 -0500
> @@ -89,9 +89,12 @@
>  
>        ByteArrayInputStream bais = new ByteArrayInputStream(serializedForm);
>        MarshalledValueInputStream mvis = new MarshalledValueInputStream(bais);
> +      try { 
>        Object retValue =  mvis.readObject();
> -      mvis.close();
>        return retValue;
> +      } finally { 
> +        mvis.close();
> +      } 
>     }
>  
>     public byte[] toByteArray()
> --- jboss-20060308-orig/src/main/org/jboss/invocation/pooled/interfaces/PooledMarshalledValue.java	2006-03-08 16:29:48.055816700 -0500
> +++ jboss-20060308/src/main/org/jboss/invocation/pooled/interfaces/PooledMarshalledValue.java	2006-03-08 17:34:20.946787700 -0500
> @@ -90,9 +90,12 @@
>  
>        ByteArrayInputStream bais = new ByteArrayInputStream(serializedForm);
>        ObjectInputStream mvis = new OptimizedObjectInputStream(bais);
> +      try { 
>        Object retValue =  mvis.readObject();
> -      mvis.close();
>        return retValue;
> +      } finally { 
> +        try { mvis.close(); } catch (Exception e) { } 
> +      } 
>     }
>  
>     public byte[] toByteArray()
> --- jboss-20060308-orig/src/main/org/jboss/naming/HttpNamingContextFactory.java	2006-03-08 16:29:48.914421700 -0500
> +++ jboss-20060308/src/main/org/jboss/naming/HttpNamingContextFactory.java	2006-03-08 17:35:39.213414500 -0500
> @@ -132,8 +132,12 @@
>  
>        InputStream is = conn.getInputStream();
>        ObjectInputStream ois = new ObjectInputStream(is);
> -      MarshalledValue mv = (MarshalledValue) ois.readObject();
> -      ois.close();
> +      MarshalledValue mv = null;
> +      try { 
> +        mv = (MarshalledValue) ois.readObject();
> +      } finally { 
> +        try { ois.close(); } catch (Exception e) { } 
> +      } 
>  
>        Object obj = mv.get();
>        if( (obj instanceof Naming) == false )
> --- jboss-20060308-orig/src/main/org/jboss/web/AbstractWebContainer.java	2006-03-08 16:29:49.413973700 -0500
> +++ jboss-20060308/src/main/org/jboss/web/AbstractWebContainer.java	2006-03-08 17:37:40.449341300 -0500
> @@ -322,8 +322,11 @@
>                 throw new DeploymentException("Was unable to mkdir: "+expWarFile);
>              log.debug("Unpacking war to: "+expWarFile);
>              FileInputStream fis = new FileInputStream(warFile);
> +            try { 
>              JarUtils.unjar(fis, expWarFile);
> -            fis.close();
> +            } finally { 
> +              try { fis.close(); } catch (Exception e) { } 
> +            } 
>              log.debug("Replaced war with unpacked contents");
>              if (warFile.delete() == false)
>                 log.debug("Was unable to delete war file");
> @@ -416,6 +419,7 @@
>              
>              FileInputStream fis = new FileInputStream(warFile);
>              JarInputStream jin = new JarInputStream(fis);
> +            try { 
>              ZipEntry entry = jin.getNextEntry();
>              while (entry != null)
>              {
> @@ -426,8 +430,9 @@
>                 }
>                 entry = jin.getNextEntry();
>              }
> -            jin.close();
> -            
> +            } finally { 
> +              try { jin.close(); } catch (Exception e) { } 
> +            } 
>              URL[] urlArr = new URL[urlList.size()];
>              urlList.toArray(urlArr);
>              di.annotationsCl = new URLClassLoader(urlArr, di.ucl);
> @@ -706,6 +711,7 @@
>              // First check for a WEB-INF/web.xml and a WEB-INF/jboss-web.xml
>              InputStream warIS = warURL.openStream();
>              java.util.zip.ZipInputStream zipIS = new java.util.zip.ZipInputStream(warIS);
> +            try { 
>              java.util.zip.ZipEntry entry;
>              byte[] buffer = new byte[512];
>              int bytes;
> @@ -730,7 +736,9 @@
>                    jbossWebIS = new ByteArrayInputStream(baos.toByteArray());
>                 }
>              }
> -            zipIS.close();
> +            } finally { 
> +              try { zipIS.close(); } catch (Exception e) { } 
> +            } 
>           }
>  
>           XmlFileLoader xmlLoader = new XmlFileLoader();
> --- jboss-20060308-orig/src/main/org/jboss/web/WebServer.java	2006-03-08 16:29:49.445195700 -0500
> +++ jboss-20060308/src/main/org/jboss/web/WebServer.java	2006-03-08 17:38:28.403080100 -0500
> @@ -1,4 +1,4 @@
> -/*
> +/* } catch (Exception e) { } 
>  * JBoss, Home of Professional Open Source
>  * Copyright 2005, JBoss Inc., and individual contributors as indicated
>  * by the @authors tag. See the copyright.txt in the distribution for a
> @@ -521,6 +521,7 @@
>     protected byte[] getBytes(URL url) throws IOException
>     {
>        InputStream in = new BufferedInputStream(url.openStream());
> +      try { 
>        log.debug("Retrieving " + url);
>        ByteArrayOutputStream out = new ByteArrayOutputStream();
>        byte[] tmp = new byte[1024];
> @@ -529,8 +530,10 @@
>        {
>           out.write(tmp, 0, bytes);
>        }
> -      in.close();
>        return out.toByteArray();
> +      } finally { 
> +        try { in.close(); } catch (Exception e) { } 
> +      } 
>     }
>  
>     /**
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCDB2IdentityValLocalCreateCommand.java	2006-03-08 16:29:45.323891700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCDB2IdentityValLocalCreateCommand.java	2006-03-08 17:19:47.443491800 -0500
> @@ -44,8 +44,9 @@
>      protected int executeInsert(int paramIndex, PreparedStatement ps, EntityEnterpriseContext ctx ) throws SQLException {
>          int rows = ps.executeUpdate();
>          ResultSet results = null;
> +        Connection conn = null; 
>          try {
> -            Connection conn = ps.getConnection();
> +            conn = ps.getConnection();
>              results = conn.prepareStatement( SQL ).executeQuery();
>              if( !results.next() ) {
>                  throw new EJBException( "identity_val_local() returned an empty ResultSet" );
> @@ -58,6 +59,7 @@
>              throw new EJBException( "Error extracting identity_val_local()", e );
>          } finally {
>              JDBCUtil.safeClose( results );
> +            JDBCUtil.safeClose(con);
>          }
>          return rows;
>      }
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCPostgreSQLCreateCommand.java	2006-03-08 16:29:45.355113700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCPostgreSQLCreateCommand.java	2006-03-08 17:22:01.854042800 -0500
> @@ -74,11 +74,12 @@
>  
>        Statement s = null;
>        ResultSet rs = null;
> +      Connection c = null;
>        try {
>           if (trace) {
>              log.trace("Executing SQL :"+sequenceSQL);
>           }
> -         Connection c = ps.getConnection();
> +         c = ps.getConnection();
>           s = c.createStatement();
>           rs = s.executeQuery(sequenceSQL);
>           if (!rs.next()) {
> @@ -93,6 +94,7 @@
>        } finally {
>           JDBCUtil.safeClose(rs);
>           JDBCUtil.safeClose(s);
> +         JDBCUtil.safeClose(c);
>        }
>  
>        return rows;
> --- jboss-20060308-orig/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCSQLServerCreateCommand.java	2006-03-08 16:29:45.355113700 -0500
> +++ jboss-20060308/src/main/org/jboss/ejb/plugins/cmp/jdbc/keygen/JDBCSQLServerCreateCommand.java	2006-03-08 17:23:29.513540100 -0500
> @@ -61,10 +61,10 @@
>  
>     protected int executeInsert(int index, PreparedStatement ps, EntityEnterpriseContext ctx) throws SQLException
>     {
> -      ps.execute();
>        ResultSet rs = null;
>        try
>        {
> +         ps.execute();
>           int rows = ps.getUpdateCount();
>           if(rows != 1)
>           {
> @@ -95,6 +95,7 @@
>        finally
>        {
>           JDBCUtil.safeClose(rs);
> +         JDBCUtil.safeClose(ps);
>        }
>     }
>  }

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 12:52:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Mon, 25 Sep 2006 12:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3678)
 org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase
 fails on Solaris 10
In-Reply-To: <26367992.1158768901179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24139418.1159203121272.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3678?page=comments#action_12343977 ] 
            
Dimitris Andreadis commented on JBAS-3678:
------------------------------------------

Is this supposedly linked to JBAS-3651?

> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> ------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3678
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3678
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: Sparc Solaris 10
> jdk 1.4.2_08
>            Reporter: Phillip Thurmond
>         Assigned To: Ryan Campbell
>
> org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase fails on Solaris 10
> Testcase: testMyService took 1.656 sec
>         Caused an ERROR
> null
> java.lang.ExceptionInInitializerError
>         at java.lang.Class.forName0(Native Method)
>         at java.lang.Class.forName(Class.java:141)
>         at org.jboss.ws.soap.attachment.ContentHandlerRegistry.<clinit>(ContentHandlerRegistry.java:5
> 1)
>         at org.jboss.ws.soap.attachment.AttachmentPartImpl.<clinit>(AttachmentPartImpl.java:56)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.getAttachmentPart(SOAPBindingProvider.java:6
> 14)
>         at org.jboss.ws.binding.soap.SOAPBindingProvider.bindRequestMessage(SOAPBindingProvider.java:
> 137)
>         at org.jboss.ws.binding.soap.SOAP11BindingProvider.bindRequestMessage(SOAP11BindingProvider.j
> ava:58)
>         at org.jboss.ws.jaxrpc.CallImpl.invokeInternal(CallImpl.java:647)
>         at org.jboss.ws.jaxrpc.CallImpl.invoke(CallImpl.java:398)
>         at org.jboss.test.webservice.attachmentstepbystep.MyServiceClientTestCase.testMyService(MySer
> viceClientTestCase.java:70)
>         at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
>         at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
>         at junit.extensions.TestSetup.run(TestSetup.java:23)
> Caused by: java.lang.IllegalArgumentException: failed to parse:image/bmp, image/x-bmp, image/x-window
> s-bmp
>         at java.awt.datatransfer.DataFlavor.<init>(DataFlavor.java:299)
>         at javax.activation.ActivationDataFlavor.<init>(ActivationDataFlavor.java:64)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.buildFlavors(ImageDataContentHandler.
> java:77)
>         at org.jboss.ws.soap.attachment.ImageDataContentHandler.<clinit>(ImageDataContentHandler.java
> :63)
>         ... 31 more

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 13:19:01 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Mon, 25 Sep 2006 13:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1318686.1159204741155.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3651?page=comments#action_12343980 ] 
            
Rajesh Rajasekaran commented on JBAS-3651:
------------------------------------------

The Solaris 10 box in the QA lab has been down. Still waiting on IT to get it back up and running.

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Ryan Campbell
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 13:31:01 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Mon, 25 Sep 2006 13:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21934628.1159205461348.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3693?page=all ]

Weston Price resolved JBAS-3693.
--------------------------------

    Fix Version/s: JBossAS-4.0.5.CR1
                       (was: JBossAS-4.0.5.GA)
       Resolution: Done

Changed behavior for destroying XA resource on XAResource.end failure. Connections are no longer returned to the pool.

> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:10:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Mon, 25 Sep 2006 14:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3676) Upgrade
 jboss-common to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1196736.1159207801190.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3676?page=comments#action_12343983 ] 
            
Scott M Stark commented on JBAS-3676:
-------------------------------------

Depends on the 1.0.0.GA release of common:
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&pid=12310265&fixfor=12310992

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Mon Sep 25 14:13:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Mon, 25 Sep 2006 14:13:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCOMMON-11) Add a default
 client socket factory which supports setBindAddress
Message-ID: <7633012.1159207981178.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a default client socket factory which supports setBindAddress
-----------------------------------------------------------------

                 Key: JBCOMMON-11
                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-11
             Project: JBoss Common
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: core
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: 1.0.0.GA


We need to have a default RMIClientSocketFactory impl that supports setBindAddress(String) for use in the invokers/naming service.


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:31:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 14:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-8) Port
 MarshalledValueIn(Out)putStream from aop
In-Reply-To: <14481718.1158259595983.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27165723.1159209061228.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-8?page=all ]

Brian Stansberry closed JBCOMMON-8.
-----------------------------------

    Fix Version/s: 1.0.0.GA
                       (was: 2.0.0.GA)
       Resolution: Done

> Port MarshalledValueIn(Out)putStream from aop
> ---------------------------------------------
>
>                 Key: JBCOMMON-8
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-8
>             Project: JBoss Common
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 1.0.0.GA
>
>
> A copy of AS/aop's MarshalledValueInputStream and MarshalledValueOutputStream should be added to common-core/org.jboss.util.stream.  These are prettyy straightforward extensions of the j2se ObjectStreams with only j2se dependencies.  Once a version of common with this in it is released, the other projects that use it can be converted.  Usages I'm aware of are:
> AS via its version in the server module
> AOP via its own version
> JBoss Cache via dependency on the AS's jboss-minimal.jar

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:34:01 2006
From: jira-events at jboss.com (Ryan Dewell (JIRA))
Date: Mon, 25 Sep 2006 14:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-161)
	Calendaring/scheduling
Message-ID: <20534147.1159209241801.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-161?page=comments#action_12343985 ] 
            
Ryan Dewell commented on JBSEAM-161:
------------------------------------

JMS messages, due to their asynchronous nature, may be a related problem as well.

> Calendaring/scheduling
> ----------------------
>
>                 Key: JBSEAM-161
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-161
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> We need calendared events to be processed in the scope of a Seam context. 
> We need to investigate what timer solutions make sense: jBPM, Quartz, EJB timers?

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:43:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 14:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-604) allow socket server
 invoker to accept third party requests
Message-ID: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>

allow socket server invoker to accept third party requests
----------------------------------------------------------

                 Key: JBREM-604
                 URL: http://jira.jboss.com/jira/browse/JBREM-604
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 2.0.0.GA (Boon)
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
             Fix For: 2.2.0.Beta1 (Bluto)


The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:46:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 14:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-604) allow socket
 server invoker to accept third party requests
In-Reply-To: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26660555.1159209961476.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-604?page=comments#action_12343988 ] 
            
Tom  Elrod commented on JBREM-604:
----------------------------------

The biggest issue with doing this is that is difficult to generate the remoting data needed on the server side, such as client session id and subsystem handler to route the request to.  

Have tried to do a best guess for this by getting the remote address for the calling socket and take the first supported subsystem defined withint the server invoker.  Obviously all the extra remoting features such as callbacks, leasing, etc. will not be available since thirdparty client will not be able to include the extra data needed for this on the server side.

> allow socket server invoker to accept third party requests
> ----------------------------------------------------------
>
>                 Key: JBREM-604
>                 URL: http://jira.jboss.com/jira/browse/JBREM-604
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:49:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 14:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-604) allow socket
 server invoker to accept third party requests
In-Reply-To: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24108219.1159210141047.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-604?page=comments#action_12343989 ] 
            
Tom  Elrod commented on JBREM-604:
----------------------------------

Test case: org.jboss.test.remoting.transport.socket.raw.RawTestCase

> allow socket server invoker to accept third party requests
> ----------------------------------------------------------
>
>                 Key: JBREM-604
>                 URL: http://jira.jboss.com/jira/browse/JBREM-604
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 14:55:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 14:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3695) Integrate JBC 2.0.0
	DR1 into HEAD
Message-ID: <8438968.1159210501062.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate JBC 2.0.0 DR1 into HEAD
---------------------------------

                 Key: JBAS-3695
                 URL: http://jira.jboss.com/jira/browse/JBAS-3695
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


The JBC team has cut a "JBossCache_2_0_DR1" release, which is really a pre-alpha snapshot for internal use.  Need to integrate this into HEAD so we can see the issues it raises.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 15:37:01 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Mon, 25 Sep 2006 15:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3651) Get the
 jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
In-Reply-To: <29242782.1158135943754.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10116012.1159213021217.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3651?page=all ]

Ryan Campbell reassigned JBAS-3651:
-----------------------------------

    Assignee: Rajesh Rajasekaran  (was: Ryan Campbell)

> Get the jboss-4.0-testsuite-sun-1.4 passing on Solaris 10
> ---------------------------------------------------------
>
>                 Key: JBAS-3651
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3651
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>            Priority: Critical
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to hold potential failing tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:43:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 16:43:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-553) Run AS (4.x
 and 5.x) integration tests with Messaging
Message-ID: <27353135.1159216981170.JavaMail.jira@cloud.prod.atl2.jboss.com>

Run AS (4.x and 5.x) integration tests with Messaging
-----------------------------------------------------

                 Key: JBMESSAGING-553
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-553
             Project: JBoss Messaging
          Issue Type: Task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz
            Priority: Critical
             Fix For: 1.2.0.Beta1


This is the container task for everthing required to run JBoss AS JMS integration tests with JBoss Messaging. The existing integration test framework should be modified in such a manner to allow interchangeably running the same JMS tests with JBossMQ and JBoss Messaging. None of the existing JBossMQ tests should be removed, they must be at most refactored so the JBossMQ-specific tests will be executed with JBossMQ only (as part of the JBossMQ functional testsuite) and generic JMS tests will be executed with both JBossMQ and JBoss Messaging.

More details in the sub-tasks.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:49:02 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 16:49:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3696) WebServices leaking
	redeployment
Message-ID: <32740588.1159217342062.JavaMail.jira@cloud.prod.atl2.jboss.com>

WebServices leaking redeployment
--------------------------------

                 Key: JBAS-3696
                 URL: http://jira.jboss.com/jira/browse/JBAS-3696
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Clebert Suconic
         Assigned To: Thomas Diesler
            Priority: Blocker
             Fix For: JBossAS-4.0.5.GA


org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata.

The current failures we are having on the TestSuite (OOME) are related to this task.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:55:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 16:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-554) Create an
 Admin abstraction
 that would allow running generic JMS tests regardless of provider
 implementation
Message-ID: <10709624.1159217701106.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create an Admin abstraction that would allow running generic JMS tests regardless of provider implementation
------------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-554
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-554
             Project: JBoss Messaging
          Issue Type: Sub-task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz
             Fix For: 1.2.0.Beta1


Since Messaging and JBossMQ use slightly different ways of deploying their administered objects (destinations and connection factories), we need to create an unified Admin interface that would allow to deploy these artifacts regardless of provider implementation, and then create plug-ins for Messaging and MQ. 

Initial work in this direction has been done by Adrian, see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:58:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 16:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3696) WebServices leaking
 redeployment
In-Reply-To: <32740588.1159217342062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15489905.1159217881526.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3696?page=comments#action_12343996 ] 
            
Clebert Suconic commented on JBAS-3696:
---------------------------------------

my suggestion for a fix would be to modify destory on ServiceEndpointDeployer:

   public void destroy(UnifiedDeploymentInfo udi) throws Throwable
   {
      log.debug("destroy: " + udi.url);

      UnifiedMetaData wsMetaData = getUnifiedMetaData(udi);
      if (wsMetaData != null)
      {
         // Destroy the service endpoints
         for (ServiceMetaData serviceMetaData : wsMetaData.getServices())
         {
            for (EndpointMetaData epMetaData : serviceMetaData.getEndpoints())
            {
               ObjectName sepID = ((ServerEndpointMetaData)epMetaData).getServiceEndpointID();
               epManager.destroyServiceEndpoint(sepID);
            }
         }
      }
      
      removeUnifiedMetaData(udi);
   }

   public void removeUnifiedMetaData(UnifiedDeploymentInfo udi)
   {
      metaDataMap.remove(udi.url.toExternalForm());
   }


> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3696
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata.
> The current failures we are having on the TestSuite (OOME) are related to this task.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 16:58:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 16:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-555) Separate
	generic JMS tests
Message-ID: <16889647.1159217881881.JavaMail.jira@cloud.prod.atl2.jboss.com>

Separate generic JMS tests
--------------------------

                 Key: JBMESSAGING-555
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-555
             Project: JBoss Messaging
          Issue Type: Sub-task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz
             Fix For: 1.2.0.Beta1


Separate the generic JMS tests by creating a copy of all JBossMQ tests and eliminating the JBossMQ-specific ones. The remaining tests will be refactored so they can be run with both Messaging and JBossMQ,

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:01:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-556) Isolate
 JBossMQ-specific test
Message-ID: <185690.1159218061132.JavaMail.jira@cloud.prod.atl2.jboss.com>

Isolate JBossMQ-specific test
-----------------------------

                 Key: JBMESSAGING-556
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-556
             Project: JBoss Messaging
          Issue Type: Sub-task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Richard Achmatowicz


Isolate JbossMQ specific tests so they'll be run as the JBossMQ functional testsuite, and NOT as integration tests.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:04:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-385) Generalize
 jboss testsuite
 JMS tests to work with both Messaging and JBossMQ (where possible) and make
 sure they pass
Message-ID: <6055369.1159218241399.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-385?page=all ]

Ovidiu Feodorov closed JBMESSAGING-385.
---------------------------------------

    Resolution: Duplicate Issue

Duplicate of http://jira.jboss.org/jira/browse/JBMESSAGING-555

> Generalize jboss testsuite JMS tests to work with both Messaging and JBossMQ (where possible) and make sure they pass
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-385
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-385
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: AS Integration
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.1
>
>
> More details on how to do that: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:04:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-386) Isolate
 JBossMQ-specific tests and make sure they pass
Message-ID: <22163649.1159218241649.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-386?page=all ]

Ovidiu Feodorov closed JBMESSAGING-386.
---------------------------------------

    Resolution: Duplicate Issue

Duplicate of http://jira.jboss.org/jira/browse/JBMESSAGING-556

> Isolate JBossMQ-specific tests and make sure they pass
> ------------------------------------------------------
>
>                 Key: JBMESSAGING-386
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-386
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.1
>
>
> Move them inside the JBossMQ project as functional tests

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:07:01 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-185) Run objectweb
 JMS tests in top of JBoss Messaging
Message-ID: <30000533.1159218421250.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-185?page=all ]

Ovidiu Feodorov reassigned JBMESSAGING-185:
-------------------------------------------

    Assignee: Richard Achmatowicz

> Run objectweb JMS tests in top of JBoss Messaging
> -------------------------------------------------
>
>                 Key: JBMESSAGING-185
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-185
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Richard Achmatowicz
>             Fix For: 1.2.1
>
>   Original Estimate: 4 days
>  Remaining Estimate: 4 days
>


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:16:03 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Mon, 25 Sep 2006 17:16:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-553) Run AS (4.x
 and 5.x) integration tests with Messaging
In-Reply-To: <27353135.1159216981170.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14996750.1159218963463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-553?page=all ]

Ovidiu Feodorov updated JBMESSAGING-553:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3974027

> Run AS (4.x and 5.x) integration tests with Messaging
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-553
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-553
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Richard Achmatowicz
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>
> This is the container task for everthing required to run JBoss AS JMS integration tests with JBoss Messaging. The existing integration test framework should be modified in such a manner to allow interchangeably running the same JMS tests with JBossMQ and JBoss Messaging. None of the existing JBossMQ tests should be removed, they must be at most refactored so the JBossMQ-specific tests will be executed with JBossMQ only (as part of the JBossMQ functional testsuite) and generic JMS tests will be executed with both JBossMQ and JBoss Messaging.
> More details in the sub-tasks.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:22:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3696) WebServices leaking
	redeployment
In-Reply-To: <32740588.1159217342062.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11532640.1159219321314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3696?page=all ]

Clebert Suconic updated JBAS-3696:
----------------------------------

    Description: 
org.jboss.ws.metadata.UnifiedMetaData has two strong references * to ClassLoader, and Undeployers are not releasing references to the metadata.
The one is showing up on my reports is field classLoader on UnifiedMetaData

The current failures we are having on the TestSuite (OOME) are related to this task.


*= strong reference is just a regular reference (non Weak, non Soft)

  was:
org.jboss.ws.metadata.UnifiedMetaData has lots of strong references to ClassLoader, and Undeployers are not releasing references to the metadata.

The current failures we are having on the TestSuite (OOME) are related to this task.


> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3696
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> org.jboss.ws.metadata.UnifiedMetaData has two strong references * to ClassLoader, and Undeployers are not releasing references to the metadata.
> The one is showing up on my reports is field classLoader on UnifiedMetaData
> The current failures we are having on the TestSuite (OOME) are related to this task.
> *= strong reference is just a regular reference (non Weak, non Soft)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:28:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:28:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <21624541.1159219723903.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Description: 
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

  was:
It's possible to use JVMTIInterface from JBossProfiler to validate if an undeployment is releasing classes, by doing assertions on certain queries made to JVMTI.

Example:


		jvmtiInterface.forceGC();
		Object[] classes = jvmtiInterface.getAllObjects(Class.class);

                Class classFound;		
		for (int i=0;i<classes.length;i++)
		{
			Class theClass = (Class)classes[i];
			if (theClass.getName().equals("org.jboss.test.SomeEJB"))
			{
				classFound=theClass;
			}
		}

                if (classFound)
                {
                           fail("Undeployment couldn't clean org.jboss.test.SomeEJB");
                }


Of course that feature will be optional, and used in certain testcases only. This way we will assure that memory leaks are not introduced on tested places.

     Complexity: High

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:40:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <25379337.1159220401223.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Description: 
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:

                jvmtiInterface.forceReleaseOfGC();
                Class[] classes = jvmtiInterface.getLoadedClasses();



  was:
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).


> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:46:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <21733650.1159220761570.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Comment: was deleted

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:46:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <2517070.1159220761723.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Comment: was deleted

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:46:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <5609733.1159220761846.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Description: 
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:

                jvmtiInterface.forceReleaseOfGC();
                Class[] classes = jvmtiInterface.getLoadedClasses();



  was:
We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).

Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)

To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).

This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:

                jvmtiInterface.forceReleaseOfGC();
                Class[] classes = jvmtiInterface.getLoadedClasses();




> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:49:01 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Mon, 25 Sep 2006 17:49:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2909) Testcase infra
 structure for MemoryLeaks
Message-ID: <25116454.1159220941162.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2909?page=all ]

Clebert Suconic updated JBAS-2909:
----------------------------------

    Assignee: Rajesh Rajasekaran  (was: Clebert Suconic)

> Testcase infra structure for MemoryLeaks
> ----------------------------------------
>
>                 Key: JBAS-2909
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2909
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Clebert Suconic
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-5.0.1.CR1
>
>
> We could modify JBossTestCase::deploy to introspect every package being deployed and write details to a list. (say the name of the loaded classes, the name of the package and the name of the test).
> Later before stopping the server on the testsuite, we should introspect loaded classes on the server and compare to the list. The intersection should be zero.
> Also before doing such comparisson is a good idea to force an OutOfMemoryError, forcing eventual SoftReferences being released (e.g. JavaSerialization or any other Reflection cache)
> To load the list we could use -XX:PrintClassHIstogram with a kill -3 on the server, or JVMTIInterface from JBossProfiler could also give you such list (by using a couple of methods for that).
> This is an example of how to list loaded classes using JVMTIInterface from JBossProfiler:
>                 jvmtiInterface.forceReleaseOfGC();
>                 Class[] classes = jvmtiInterface.getLoadedClasses();

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:55:01 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Mon, 25 Sep 2006 17:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCOMMON-11) Add a default
 client socket factory which supports setBindAddress
In-Reply-To: <7633012.1159207981178.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22564337.1159221301267.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-11?page=all ]

Scott M Stark closed JBCOMMON-11.
---------------------------------

    Fix Version/s: 2.0.1.GA
       Resolution: Done

org.jboss.net.sockets.DefaultClientSocketFactory has been added to the common-core.

> Add a default client socket factory which supports setBindAddress
> -----------------------------------------------------------------
>
>                 Key: JBCOMMON-11
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-11
>             Project: JBoss Common
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: core
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.0.0.GA, 2.0.1.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> We need to have a default RMIClientSocketFactory impl that supports setBindAddress(String) for use in the invokers/naming service.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 17:55:01 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Mon, 25 Sep 2006 17:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1047) Design ldap
 implementation for identity modules
In-Reply-To: <3389991.1158568372948.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25543997.1159221301580.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1047?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1047.
-------------------------------------------

    Resolution: Done

> Design ldap implementation for identity modules
> -----------------------------------------------
>
>                 Key: JBPORTAL-1047
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1047
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Identity
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 3 days, 1 hour
>
> - Identity modules must handle both user/role retreival and creation 
> - User and roles can be mapped in ldap directory tree in several different ways.
> - There should be some flexible implementation desinged to handle different user/roles relations mapping strategies. (roles, group, both static and dynamic)
> - This should also be opened for additional specific features for main LDAP implementations (RH, Sun, MSAD...)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:19:02 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 18:19:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBCACHE-465) Refactor state
 transfer code out of TreeCache
Message-ID: <33048198.1159222742222.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-465?page=all ]

Brian Stansberry closed JBCACHE-465.
------------------------------------

    Resolution: Done

> Refactor state transfer code out of TreeCache
> ---------------------------------------------
>
>                 Key: JBCACHE-465
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-465
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: 2.0.0
>
>
> The TreeCache class now has a ton of code related to state transfer.  Need to look into refactoring that out into a separate class or classes.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:22:02 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 18:22:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25716879.1159222922038.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3659?page=all ]

Brian Stansberry updated JBAS-3659:
-----------------------------------

    Description: 
The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.

We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB receive buffers  and 640K send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the send buffers to 640K and the receives to 2MB.

  was:
The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.

We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the receive buffers to 640K and the sends to perhaps 2MB.


> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB receive buffers  and 640K send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the send buffers to 640K and the receives to 2MB.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:25:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Mon, 25 Sep 2006 18:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3659) Increase
 ClusterPartition buffers to support farming of large files
In-Reply-To: <16735311.1158330996558.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16033403.1159223101043.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3659?page=all ]

Brian Stansberry closed JBAS-3659.
----------------------------------

    Resolution: Done

> Increase ClusterPartition buffers to support farming of large files
> -------------------------------------------------------------------
>
>                 Key: JBAS-3659
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3659
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> The receive buffers in the cluster-service.xml UDP protocol are only 150K.  Farming sends files around the cluster in 512K chunks.  With the default config, the receive buffer sizes are not even large enough to hold one chunk.  This can lead to problems where the packets that make up part of a chunk get dropped and have to be retransmitted.  With very large files, this can slow things down to the point that timeouts start getting tripped and the transfer fails.
> We had a support case where increasing the buffers to the sizes used by the fc-fast-minimalthreads config took care of the problem.  That config uses 25MB receive buffers  and 640K send buffers for both mcast and unicast; don't think we need to increase to such a high number for this.  But, I will bump the send buffers to 640K and the receives to 2MB.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:02 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-59) get original BPEL
 document after deployment
Message-ID: <6743049.1159224362383.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-59?page=all ]

Alejandro Guizar updated BPEL-59:
---------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> get original BPEL document after deployment
> -------------------------------------------
>
>                 Key: BPEL-59
>                 URL: http://jira.jboss.com/jira/browse/BPEL-59
>             Project: JBoss jBPM BPEL
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 3
>            Reporter: Dmitry
>         Assigned To: Alejandro Guizar
>            Priority: Minor
>             Fix For: jBPM BPEL 1.1
>
>
> i'm developing a BAM system(http://sourceforge.net/projects/jbam). and i need on my presentation part of the system show the user on what step of the execution of the process are we currently on. i'm intercepting JBPM system ivents via JBossAOP framework, and as a reason of it have no problem to know on which step of process instance execution are we currently on and what is my input data, but i can't meanwhile to find way to get process flow definition. according to my design i would like to get on each processinstance start a process xml model so i could transform it to SVG and show to end user on portal(the representation on my system). this is needed becouse process might have different versions and i'd like to show to user the updated one or busuness analyst might what to know how did the process flow looked two month ago, and this information i can give him from my database if i have xml definition stored inside it.
> Regards,
> Dmitry.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:02 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-10) compensation handling
Message-ID: <5826820.1159224362789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-10?page=all ]

Alejandro Guizar updated BPEL-10:
---------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> compensation handling
> ---------------------
>
>                 Key: BPEL-10
>                 URL: http://jira.jboss.com/jira/browse/BPEL-10
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Juan Cantu
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> -Implement the state transitions for scope instances when compensate / compensated signals are received 
> -support implicit compensation

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:02 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-193) template for new
	projects
Message-ID: <5287690.1159224362909.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-193?page=all ]

Alejandro Guizar updated BPEL-193:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> template for new projects
> -------------------------
>
>                 Key: BPEL-193
>                 URL: http://jira.jboss.com/jira/browse/BPEL-193
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Burr Sutter wrote:
> "I was only hoping for an easy way to build, modify and redeploy HelloWorld or ATM with the least amount of effort.  Something like
> 1. Edit BPEL file
> 2. Deploy
> 3. In the browser view the WSDL
> Having Ant tasks that make it this easy and a template project and build script for getting started would be great for the first release of our BPEL engine."

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-200) Redeployment of a
 changed PAR (with modified .bpel) requires App Server Restart
In-Reply-To: <16886597.1153430291450.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22491588.1159224363534.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-200?page=all ]

Alejandro Guizar updated BPEL-200:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> Redeployment of a changed PAR (with modified .bpel) requires App Server Restart
> -------------------------------------------------------------------------------
>
>                 Key: BPEL-200
>                 URL: http://jira.jboss.com/jira/browse/BPEL-200
>             Project: JBoss jBPM BPEL
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.1 beta 1
>         Environment: JBoss 4.0.4.GA with EJB3 using beta JEMS installer 
>            Reporter: Burr Sutter
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Simply modifying the .bpel script, running pack-definition and deploy-definition do not reload/restart the process (even though all process instances have terminated).  The only thing I've found that refreshes the BPEL engine properly is to restart the App Server.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-168) soap header processing
Message-ID: <15539127.1159224363696.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-168?page=all ]

Alejandro Guizar updated BPEL-168:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> soap header processing
> ----------------------
>
>                 Key: BPEL-168
>                 URL: http://jira.jboss.com/jira/browse/BPEL-168
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Extract the WSDL message parts carried in SOAP headers and add them to incoming requests.
> Make sure this mechanism properly makes WS-Addressing headers available to the process.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-201) Release 1.1 beta 3
In-Reply-To: <4511003.1153758791655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31354993.1159224363822.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-201?page=all ]

Alejandro Guizar updated BPEL-201:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> Release 1.1 beta 3
> ------------------
>
>                 Key: BPEL-201
>                 URL: http://jira.jboss.com/jira/browse/BPEL-201
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> The focus of this release is on fault handlers and compensation.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:03 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:03 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-151) export the reference
 of the published endpoint
Message-ID: <30788981.1159224363974.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-151?page=all ]

Alejandro Guizar updated BPEL-151:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> export the reference of the published endpoint
> ----------------------------------------------
>
>                 Key: BPEL-151
>                 URL: http://jira.jboss.com/jira/browse/BPEL-151
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 3
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>            Priority: Critical
>             Fix For: jBPM BPEL 1.1
>
>
> Provide the endpoint reference of the process with respect to partner links. Implement its use as the source of assignment, as described in section 9.4 of the spec.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:04 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-144) publish
	document/literal endpoints
Message-ID: <17323294.1159224364119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-144?page=all ]

Alejandro Guizar updated BPEL-144:
----------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> publish document/literal endpoints
> ----------------------------------
>
>                 Key: BPEL-144
>                 URL: http://jira.jboss.com/jira/browse/BPEL-144
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>         Environment: jaxrpc, saaj, w3c dom
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> jBPM BPEL currently generates service WSDL documents and processes SOAP request/response messages only for RPC/literal web services. Enhancing the service generation tool and the JAX-RPC handler to cover the document style is crucial for interoperability, particulary with .NET.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:04 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-9) fault and termination
	handling
Message-ID: <19191364.1159224364371.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-9?page=all ]

Alejandro Guizar updated BPEL-9:
--------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 3)

> fault and termination handling
> ------------------------------
>
>                 Key: BPEL-9
>                 URL: http://jira.jboss.com/jira/browse/BPEL-9
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>          Components: Engine
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Juan Cantu
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> -Implement the state transitions for scope instances when cancel or faulted signals are received 
> -Provide the fault catching logic

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 18:46:04 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 18:46:04 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (BPEL-85) Docu on the purpose of
	BPEL
Message-ID: <5251899.1159224364585.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-85?page=all ]

Alejandro Guizar updated BPEL-85:
---------------------------------

    Fix Version/s: jBPM BPEL 1.1
                       (was: jBPM BPEL 1.1 beta 2)

> Docu on the purpose of BPEL
> ---------------------------
>
>                 Key: BPEL-85
>                 URL: http://jira.jboss.com/jira/browse/BPEL-85
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documents
>    Affects Versions: jBPM BPEL 1.0 alpha 4
>            Reporter: Thomas Diesler
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> Please expand the user documentation to a section about the purpose of BPEL. It should show a not so trivial use case that illustrates (with pictures) why I should care about BPEL

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 19:22:01 2006
From: jira-events at jboss.com (Ron Sigal (JIRA))
Date: Mon, 25 Sep 2006 19:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-605) Inform a server side
 listener that a callback has been delivered.
Message-ID: <32739313.1159226521194.JavaMail.jira@cloud.prod.atl2.jboss.com>

Inform a server side listener that a callback has been delivered.
-----------------------------------------------------------------

                 Key: JBREM-605
                 URL: http://jira.jboss.com/jira/browse/JBREM-605
             Project: JBoss Remoting
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.0.Beta1 (Bluto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.2.0.Beta1 (Bluto)


JBossMessaging has a need to know that a Callback has been pulled to the client side and has been processed. 

See JBMESSAGING-207 for some discussion.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 19:58:01 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Mon, 25 Sep 2006 19:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (BPEL-212) Modularize package
 org.jbpm.bpel.def
Message-ID: <7572.1159228681195.JavaMail.jira@cloud.prod.atl2.jboss.com>

Modularize package org.jbpm.bpel.def
------------------------------------

                 Key: BPEL-212
                 URL: http://jira.jboss.com/jira/browse/BPEL-212
             Project: JBoss jBPM BPEL
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: jBPM BPEL 1.1 beta 2
            Reporter: Alejandro Guizar
         Assigned To: Alejandro Guizar
             Fix For: jBPM BPEL 1.1


The package org.jbpm.bpel.def concentrates all activity definitions and has become monolithic. The proposal is breaking it as follows:

org.jbpm.bpel.graph.def: Core concepts, including BpelDefinition, Activity, CompositeActivity and LinkDefinition.
org.jbpm.bpel.graph.basic: Basic activities
org.jbpm.bpel.graph.struct: Structured activities
org.jbpm.bpel.graph.scope: Scope activity plus fault, compensation, event and termination handlers

For consistency, org.jbpm.bpel.exe becomes org.jbpm.bpel.graph.exe. Because the number of execution objects is small, there is no need to break this package.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:31:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-604) allow socket server
 invoker to accept third party requests
In-Reply-To: <20955932.1159209781215.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13933991.1159237861119.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-604?page=all ]

Tom  Elrod resolved JBREM-604.
------------------------------

    Resolution: Done

> allow socket server invoker to accept third party requests
> ----------------------------------------------------------
>
>                 Key: JBREM-604
>                 URL: http://jira.jboss.com/jira/browse/JBREM-604
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 2.0.0.GA (Boon)
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The http server invoker (i.e. CoyoteInvoker) allows thirdparty clients to make requests and process those requests and return raw response from handler.  Really no reason that the socket server invoker could not do this as well so that someone could write their own socket client and send raw data to the socket server invoker.

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:31:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 22:31:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-548) Support one way
 invocations with no response
In-Reply-To: <22298973.1153332911695.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12288259.1159237861306.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-548?page=all ]

Tom  Elrod resolved JBREM-548.
------------------------------

    Resolution: Done

> Support one way invocations with no response
> --------------------------------------------
>
>                 Key: JBREM-548
>                 URL: http://jira.jboss.com/jira/browse/JBREM-548
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Tim Fox
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The current remoting implementation of a client side one way invocations just performs a standard two way invocation on a different thread and returns without waiting for the result.
> JBoss Messaging would like to have a one way invocation which just performs a write to the underlying stream (e.g. socket outpustream) and continues without waiting for the result. This would result in less blocking and better performance since redundant writes for the invocation response would be ommitted,

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:34:01 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Mon, 25 Sep 2006 22:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-548) Support one way
 invocations with no response
In-Reply-To: <22298973.1153332911695.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2272682.1159238041275.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-548?page=comments#action_12344022 ] 
            
Tom  Elrod commented on JBREM-548:
----------------------------------

For the socket invoker and making oneway call, the client will only write data to wire and return without waiting to read data off the wire and the server will only read data from the wire and will throw away handler response and will not write it to the wire.

> Support one way invocations with no response
> --------------------------------------------
>
>                 Key: JBREM-548
>                 URL: http://jira.jboss.com/jira/browse/JBREM-548
>             Project: JBoss Remoting
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Tim Fox
>         Assigned To: Tom  Elrod
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> The current remoting implementation of a client side one way invocations just performs a standard two way invocation on a different thread and returns without waiting for the result.
> JBoss Messaging would like to have a one way invocation which just performs a write to the underlying stream (e.g. socket outpustream) and continues without waiting for the result. This would result in less blocking and better performance since redundant writes for the invocation response would be ommitted,

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 22:58:01 2006
From: jira-events at jboss.com (Daniel Brum (JIRA))
Date: Mon, 25 Sep 2006 22:58:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-149) Refactor Object
 Store as per design goals for G.A release
Message-ID: <27758571.1159239481343.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor Object Store as per design goals for G.A release
---------------------------------------------------------

                 Key: JBESB-149
                 URL: http://jira.jboss.com/jira/browse/JBESB-149
             Project: JBoss ESB
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Daniel Brum
         Assigned To: Daniel Brum
             Fix For: 4.0


Change Rosetta Object Store implementation to support Re-Architecture Message changes.
- remove EJB dependency, standalone service
- change DB pool logic (Apache project?)
- support persisting and lookup of Message
- pluggable persistence engine, i.e: database or file, or other.  For G.A only database to be supported


-- 
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

        


From jira-events at jboss.com  Mon Sep 25 23:01:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Mon, 25 Sep 2006 23:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-785) InvocationContext
 and suspended transactions
Message-ID: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>

InvocationContext and suspended transactions
--------------------------------------------

                 Key: JBCACHE-785
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani


The attached test case demonstrates that if you:

 A) Make calls to the tree cache
 B) suspend the current transaction
 C) Make more calls to the tree cache

The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.

It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Mon Sep 25 23:04:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Mon, 25 Sep 2006 23:04:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-785) InvocationContext
 and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16214092.1159239841297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=all ]

Owen Taylor updated JBCACHE-785:
--------------------------------

    Attachment: SuspendTxTest.java

> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>         Attachments: SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:07:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 00:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3697) Port BR test of
 ClusteredSSO to HEAD
Message-ID: <33382617.1159243621195.JavaMail.jira@cloud.prod.atl2.jboss.com>

Port BR test of ClusteredSSO to HEAD
------------------------------------

                 Key: JBAS-3697
                 URL: http://jira.jboss.com/jira/browse/JBAS-3697
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.Beta


Port to HEAD once it stabilizes and the new deployer structure is clear.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:07:01 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 00:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3487) Create test of
 ClusteredSingleSignOn with BR enabled
In-Reply-To: <31521015.1154989995283.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3746659.1159243621316.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3487?page=all ]

Brian Stansberry closed JBAS-3487.
----------------------------------

    Resolution: Done

Done in Branch_4_0.

> Create test of ClusteredSingleSignOn with BR enabled
> ----------------------------------------------------
>
>                 Key: JBAS-3487
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3487
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> Need to toggle the buddyReplicationEnabled attribute, restart and re-run.  I've already tested it works manually; need to add to suite to ensure there are no regressions.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:10:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 00:10:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-785)
 InvocationContext and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30138664.1159243801365.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=comments#action_12344024 ] 
            
Owen Taylor commented on JBCACHE-785:
-------------------------------------

I probably should also mention the context: this problem occurs with the text.hibernate.cache.TreeCache.put() which suspends the current transaction when caching data into the cache after a cache miss. I believe (but have not verified experimentally) that it will also occur with the suspend that is done internally inside the tree cache when Option.setFailSilently() has been called.


> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>         Attachments: SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 00:34:01 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 00:34:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-785) InvocationContext
 and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1569877.1159245241304.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=all ]

Owen Taylor updated JBCACHE-785:
--------------------------------

    Attachment: hibernate-suspend-workaround.patch

For reference, here's a workaround patch for Hibernate

> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>         Attachments: hibernate-suspend-workaround.patch, SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 01:40:01 2006
From: jira-events at jboss.com (uphaar kotru (JIRA))
Date: Tue, 26 Sep 2006 01:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3698) JNDI Lookup returns
	null
Message-ID: <8105736.1159249201465.JavaMail.jira@cloud.prod.atl2.jboss.com>

JNDI Lookup returns null
------------------------

                 Key: JBAS-3698
                 URL: http://jira.jboss.com/jira/browse/JBAS-3698
             Project: JBoss Application Server
          Issue Type: Release
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.3 SP1
         Environment: WIndows XP 2002 SP2
            Reporter: uphaar kotru
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.2 Final


I am having issue with jndi lookup for my datasource in 4.0.3 SP1. The jndi is getting bound properly but while I try to lookup, it returns null. 
When I use exactly same WAR file and Oracle-DS.xml on 4.0.2, it works fine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 03:25:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 03:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3698) JNDI Lookup returns
	null
Message-ID: <10134967.1159255501672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3698?page=all ]

Dimitris Andreadis closed JBAS-3698.
------------------------------------


Please, use the forums to ask for help, this is not a bug report.

> JNDI Lookup returns null
> ------------------------
>
>                 Key: JBAS-3698
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3698
>             Project: JBoss Application Server
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>         Environment: WIndows XP 2002 SP2
>            Reporter: uphaar kotru
>         Assigned To: Scott M Stark
>             Fix For: No Release
>
>
> I am having issue with jndi lookup for my datasource in 4.0.3 SP1. The jndi is getting bound properly but while I try to lookup, it returns null. 
> When I use exactly same WAR file and Oracle-DS.xml on 4.0.2, it works fine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 03:25:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 03:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Deleted: (JBAS-3698) JNDI Lookup returns
	null
Message-ID: <14063054.1159255501863.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3698?page=all ]

Dimitris Andreadis deleted JBAS-3698:
-------------------------------------


> JNDI Lookup returns null
> ------------------------
>
>                 Key: JBAS-3698
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3698
>             Project: JBoss Application Server
>          Issue Type: Release
>      Security Level: Public(Everyone can see) 
>         Environment: WIndows XP 2002 SP2
>            Reporter: uphaar kotru
>         Assigned To: Scott M Stark
>
> I am having issue with jndi lookup for my datasource in 4.0.3 SP1. The jndi is getting bound properly but while I try to lookup, it returns null. 
> When I use exactly same WAR file and Oracle-DS.xml on 4.0.2, it works fine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:16:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3699) Fix testsuite OOMEs
Message-ID: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix testsuite OOMEs
-------------------

                 Key: JBAS-3699
                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:16:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 04:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25149248.1159258561843.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3699?page=comments#action_12344027 ] 
            
Dimitris Andreadis commented on JBAS-3699:
------------------------------------------

It seems there is a memory leak during webservices redeployment (JBWS-1228) so I'm going to exclude the webservices tests for now, to proceed with the rest of the testsuite.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:22:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 04:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24093870.1159258921571.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

        Summary: Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages  (was: FileCacheLoader can return null for get(fqn) breaking the JavaDoc requirement for CacheLoader.get(fqn))
    Description: 
FileCacheLoader can return a null value for get(fqn) if the node does not exist.

 /**
    * Returns all keys and values from the persistent store, given a fully qualified name.
    *
    * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
    * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
    * implementations should be checked for compliance with the behaviour expected.
    *
    * @param name
    * @return Map<Object,Object> keys and values for the given node. Returns
    * null if the node is not found.  If the node is found but has no
    * attributes, this method returns an empty Map.
    * @throws Exception
 */

If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
following misleading warning message is logged:

10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.

This occurrs even though the FileCacheLoader is actually doing the job accordingly.

  was:
FileCacheLoader can return a null value for get(fqn) which goes against the JavaDoc 
requirements for that method:

 /**
    * Returns all keys and values from the persistent store, given a fully qualified name.
    *
    * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
    * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
    * implementations should be checked for compliance with the behaviour expected.
    *
    * @param name
    * @return Map<Object,Object> keys and values for the given node. Returns
    * null if the node is not found.  If the node is found but has no
    * attributes, this method returns an empty Map.
    * @throws Exception
 */

If a get(fqn) operation occurrs before a put and the node (directory) does not exist, FCL returns 
null when it should return an empty Map.

If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
following misleading warning message is logged:

10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.


Update the case comment and title due to misunderstanding of the javadoc.
FileCacheLoader fullfills the javadoc, but in the special occasion of having a custom
cache loader that delegates on a org.jboss.cache CacheLoader, this WARN messages
would be log thinking that the newly create custom cache loader is breaking the contract.

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 04:46:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 04:46:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3484) non portable JDK
 dependant clasess (sun.**)
In-Reply-To: <23337773.1154968092604.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20836870.1159260361700.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3484?page=all ]

Dimitris Andreadis closed JBAS-3484.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

I looked again at all cases and there is no remaining reference to sun classes.

> non portable JDK dependant clasess (sun.**)
> -------------------------------------------
>
>                 Key: JBAS-3484
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3484
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service, Security
>    Affects Versions: JBossAS-5.0.0.CR1, JBossAS-4.0.4.GA
>            Reporter: Andrew Oliver
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> We should not be using sun.** classes in tests or in code.   they are naughty and break working on non Sun JDKs.
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -i "sun.misc.BASE64Encoder" '{}' ';'
>       sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc.BASE64Encoder" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.misc" '{}' ';'
> ./security/src/main/org/jboss/test/UtilTestCase.java:   /** Compare Util.encodeBase64 against the sun misc class
> ./security/src/main/org/jboss/test/UtilTestCase.java:      sun.misc.BASE64Encoder encoder = new sun.misc.BASE64Encoder();
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * Eliminates dependency on sun.misc.Base64Encoding,
> ./jaxrpc/src/main/org/jboss/axis/utils/Base64.java: * (it's an access exception to load sun.misc.* classes
> [andy at localhost jboss-4.0.x]$ find . -name "*.java" -exec grep -Hi "sun.io" '{}' ';'
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:         sun.io.CharToByteUTF8 conv = new sun.io.CharToByteUTF8();
> ./messaging/src/main/org/jboss/mq/xml/XElement.java:      } catch ( sun.io.MalformedInputException e ) {
> [andy at localhost jboss-4.0.x]$
> Moreover the 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:07:01 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Tue, 26 Sep 2006 05:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3626) Upgrade jbossws to
	1.0.4.GA
In-Reply-To: <13703525.1157538574990.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8551371.1159261621256.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3626?page=all ]

Thomas Diesler updated JBAS-3626:
---------------------------------

    Summary: Upgrade jbossws to 1.0.4.GA  (was: Upgrade jbossws to 1.1.0.GA)

> Upgrade jbossws to 1.0.4.GA
> ---------------------------
>
>                 Key: JBAS-3626
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3626
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Dimitris Andreadis
>         Assigned To: Thomas Diesler
>             Fix For: JBossAS-4.0.6.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:22:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 05:22:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6945609.1159262521261.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

    Affects Version/s: 2.0.0

Added 2.0

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.0.0, 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:26:01 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 26 Sep 2006 05:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-785) InvocationContext
 and suspended transactions
In-Reply-To: <5765010.1159239661185.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29439343.1159262761286.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-785?page=all ]

Manik Surtani updated JBCACHE-785:
----------------------------------

    Fix Version/s: 1.4.0.SP2
                   2.0.0

> InvocationContext and suspended transactions
> --------------------------------------------
>
>                 Key: JBCACHE-785
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-785
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>             Fix For: 2.0.0, 1.4.0.SP2
>
>         Attachments: hibernate-suspend-workaround.patch, SuspendTxTest.java
>
>
> The attached test case demonstrates that if you:
>  A) Make calls to the tree cache
>  B) suspend the current transaction
>  C) Make more calls to the tree cache
> The locks created at step C) are sometimes  attached to the suspended transaction; it seems this is because the cached transactions in InvocationContext are only reliably cleared when a transaction is committed.
> It's possible that *always* passing true in the call to scrubInvocationCtx() at the end of TxInterceptor.invoke() would work, but I'm not sure it is the correct thing to do, or what the effect would be on performance. (Presumably there is some reason not to just always look up the current transaction.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 05:55:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 05:55:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27216176.1159264501127.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

    Affects Version/s:     (was: 2.0.0)

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:16:01 2006
From: jira-events at jboss.com (anajavi (JIRA))
Date: Tue, 26 Sep 2006 06:16:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3700) Declared SQL Finder
 does not work with cmp2.x jdbc2 pm
Message-ID: <16043677.1159265761680.JavaMail.jira@cloud.prod.atl2.jboss.com>

Declared SQL Finder does not work with cmp2.x jdbc2 pm
------------------------------------------------------

                 Key: JBAS-3700
                 URL: http://jira.jboss.com/jira/browse/JBAS-3700
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: anajavi
         Assigned To: Alexey Loubyansky


When using declared sql where clause in finder, the generated sql does not contain all the fields of the entity. The cmp2.x jdbc2 pm requires the query to return all the fields. This causes an exception when the finder is invoked.

This is caused by DeclaredSQLQueryCommand.java and method buildSQL:
      if(metadata.getFieldName() == null)
      {
         // we are selecting a full entity
         table = this.entity.getQualifiedTableName();

         // get a list of all fields to be loaded
         // put pk fields in front
         String tableAlias = getTableAlias(alias, from, this.entity.getTableName());
         selectList = SQLUtil.getColumnNamesClause(this.entity.getPrimaryKeyFields(),
            tableAlias,
            new StringBuffer(35)).toString();
      }


Quick fix is to change this.entity.getPrimaryKeyFields() to this.entity.getTableFields().

The configurations:

ejb-jar.xml:
         <query>
            <query-method>
               <method-name>findByNimi</method-name>
               <method-params>
                  <method-param>java.lang.String</method-param>
               </method-params>
            </query-method>
            <ejb-ql><![CDATA[SELECT OBJECT(o) FROM Yritys AS o WHERE o.nimi=?1]]></ejb-ql>
         </query>


jbosscmp-jdbc.xml:
         <query>
                        <description/>
            <query-method>
               <method-name>findByNimi</method-name>
               <method-params>
                  <method-param>java.lang.String</method-param>
               </method-params>
            </query-method>

            <declared-sql>
                <where><![CDATA[upper(nimi) like upper({0})]]></where>
            </declared-sql>
         </query>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:19:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1102468.1159265941081.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno updated JBCACHE-776:
-------------------------------------

    Fix Version/s: 1.4.0.SP2

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:28:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-776)
 EvictionPolicyProvider WARN message is noisy and misleading
In-Reply-To: <389844.1158912781177.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18835344.1159266481409.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-776?page=all ]

Galder Zamarreno resolved JBCACHE-776.
--------------------------------------

    Resolution: Done

EvictionPolicyProvider deprecated message downgraded from WARN to DEBUG.

> EvictionPolicyProvider WARN message is noisy and misleading
> -----------------------------------------------------------
>
>                 Key: JBCACHE-776
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-776
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP3, 1.4.0.SP1
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> JBoss AS 4.0.x assumes JBossCache 1.2.x which originally used EvictionPolicyProvider 
> variable to hold eviction policies. The usage of this variable has been deprecated, but 
> JBossCache 1.3.x and 1.4.x still need to set it in order to provide backwards compatibility.
> Calling setEvictionPolicyProvider() results on a misleading noisy WARN message, which :
> "Using deprecated configuration element 'EvictionPolicyProvider'.  This is only provided 
> for 1.2.x backward compatibility and may disappear in future releases."
> This message should be downgraded and the text revised.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:43:02 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Tue, 26 Sep 2006 06:43:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3350) NPE on web service
	deployment
Message-ID: <20018574.1159267382259.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3350?page=all ]

Thomas Diesler reassigned JBAS-3350:
------------------------------------

    Assignee: Remy Maucherat

Remy, could you please have a look.

> NPE on web service deployment
> -----------------------------
>
>                 Key: JBAS-3350
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3350
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Remy Maucherat
>
> tdiesler at TDDELL /cygdrive/d/svn/jbossws/trunk/src/test
> $ ant -Dtest=org.jboss.test.ws.wsse.WebClientTestCase one-test
> 2006-06-29 11:02:35,953 ERROR [org.apache.catalina.startup.ContextConfig] Parse error in application web.xml file at jndi:/localhost/jbossws-wsse-rpc/WEB-INF/web.xml
> java.lang.NullPointerException
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2725)
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2751)
> 	at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060)
> 	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
> <web-app version='2.4' xmlns='http://java.sun.com/xml/ns/j2ee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd'>
>  <servlet>
>   <servlet-name>Hello</servlet-name>
>   <servlet-class>org.jboss.ws.integration.jboss.JBossServiceEndpointServlet</servlet-class>
>   <init-param>
>    <param-name>ServiceEndpointImpl</param-name>
>    <param-value>org.jboss.test.ws.wsse.HelloJavaBean</param-value>
>   </init-param>
>  </servlet>
>  <servlet>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <servlet-class>org.jboss.test.ws.wsse.RpcTestClientServlet</servlet-class>
>  </servlet>
>  <servlet-mapping>
>   <servlet-name>Hello</servlet-name>
>   <url-pattern>/Hello</url-pattern>
>  </servlet-mapping>
>  <servlet-mapping>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <url-pattern>/RpcTestClientServlet</url-pattern>
>  </servlet-mapping>
>  <service-ref>
>   <service-ref-name>service/HelloService</service-ref-name>
>   <service-interface>javax.xml.rpc.Service</service-interface>
>   <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
>   <jaxrpc-mapping-file>WEB-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
>   <port-component-ref>
>    <service-endpoint-interface>org.jboss.test.ws.wsse.Hello</service-endpoint-interface>
>   </port-component-ref>
>  </service-ref>
> </web-app>

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:28:02 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:28:02 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7287838.1159266482179.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno updated JBCACHE-777:
-------------------------------------

    Fix Version/s: 1.4.0.SP2

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 06:28:01 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 06:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCACHE-777) Creating a
 custom cache
 loader which delegates to a standard cache loader, can generate misleading
 WARN messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15256736.1159266481994.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=comments#action_12344032 ] 
            
Galder Zamarreno commented on JBCACHE-777:
------------------------------------------

Removed 2.0 (head)

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:14:01 2006
From: jira-events at jboss.com (Tom Baeyens (JIRA))
Date: Tue, 26 Sep 2006 07:14:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-755) streamline designer
	build
Message-ID: <1177345.1159269241260.JavaMail.jira@cloud.prod.atl2.jboss.com>

streamline designer build
-------------------------

                 Key: JBPM-755
                 URL: http://jira.jboss.com/jira/browse/JBPM-755
             Project: JBoss jBPM
          Issue Type: Task
          Components: Graphical Process Designer
            Reporter: Tom Baeyens
         Assigned To: Koen Aers
            Priority: Critical


1) Remove usage of jbpm.version.  
* The docs should not be included directly in the designer plugin.  Instead, in the help docs, a reference should be published to the docs of the configured runtimes.
* The jbpm version constant should be removed cause it's not used any more.

When fixing this, make sure to do a search for jbpm.version.  

2) Rename jbpm.gpd.version to module.version so that it is in sync with all other jbpm subprojects.  Make sure that the used definition is located in the version.properties file and that the property definition in the build.xml is removed.

3) Remove all CVS checkout stuff.  Have the build fail in case one of the submodules is not present.   No cvs checkout should be done in case a module is missing.  Later we'll define a cvs checkout script in the overall build.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:19:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:19:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-133) Correct handling of
 one phase commit heuristics
Message-ID: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>

Correct handling of one phase commit heuristics
-----------------------------------------------

                 Key: JBTM-133
                 URL: http://jira.jboss.com/jira/browse/JBTM-133
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2


The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.

The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-133) Correct handling of
 one phase commit heuristics
In-Reply-To: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11063022.1159270081382.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-133?page=comments#action_12344035 ] 
            
Kevin Conner commented on JBTM-133:
-----------------------------------

Fixed in revision 6431.


> Correct handling of one phase commit heuristics
> -----------------------------------------------
>
>                 Key: JBTM-133
>                 URL: http://jira.jboss.com/jira/browse/JBTM-133
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.
> The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-102) Need for a migration
	document
In-Reply-To: <1741379.1154429291404.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6091621.1159270081727.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-102?page=all ]

Mark Little updated JBESB-102:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Need for a migration document
> -----------------------------
>
>                 Key: JBESB-102
>                 URL: http://jira.jboss.com/jira/browse/JBESB-102
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Distribution
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.1
>
>
> Because there may be some significant differences between the beta and GA releases of JBossESB 4.0, we need a migration document that summarises those changes.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:26:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 07:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-59) Add in generic bus
	abstraction
Message-ID: <22553256.1159269961911.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-59?page=all ]

Mark Little updated JBESB-59:
-----------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Add in generic bus abstraction
> ------------------------------
>
>                 Key: JBESB-59
>                 URL: http://jira.jboss.com/jira/browse/JBESB-59
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Critical
>             Fix For: 4.1
>
>          Time Spent: 1 week
>  Remaining Estimate: 0 minutes
>
> Prior to Rosetta, we had the notion of a generic bus with client/service plugins, dispatchers and a message format. All of this needs to be added back to the new codebase.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:26:01 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 07:26:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-135) Integration with
 Microcontainer (IoC abstraction)
In-Reply-To: <11365425.1157552071692.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13944806.1159269961774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-135?page=all ]

Mark Little updated JBESB-135:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> Integration with Microcontainer (IoC abstraction)
> -------------------------------------------------
>
>                 Key: JBESB-135
>                 URL: http://jira.jboss.com/jira/browse/JBESB-135
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Critical
>             Fix For: 4.1
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-133) Correct handling of
 one phase commit heuristics
In-Reply-To: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25855701.1159270081496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-133?page=all ]

Kevin Conner resolved JBTM-133.
-------------------------------

    Resolution: Done

> Correct handling of one phase commit heuristics
> -----------------------------------------------
>
>                 Key: JBTM-133
>                 URL: http://jira.jboss.com/jira/browse/JBTM-133
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.
> The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 07:28:01 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Tue, 26 Sep 2006 07:28:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-133) Correct handling of
 one phase commit heuristics
In-Reply-To: <13537326.1159269541041.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1539270.1159270081835.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-133?page=all ]

Kevin Conner closed JBTM-133.
-----------------------------


> Correct handling of one phase commit heuristics
> -----------------------------------------------
>
>                 Key: JBTM-133
>                 URL: http://jira.jboss.com/jira/browse/JBTM-133
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> The current codebase does not correctly handle heuristic rollback or heuristic commit for one phase commit.
> The resource records should be modified to call forget on the resources and handle the heuristic as if it was a normal rollback/commit.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 08:25:01 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Tue, 26 Sep 2006 08:25:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBXB-79) Array parameter is
 being appended rather than passed intact
In-Reply-To: <2775590.1156789966866.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16269866.1159273501164.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBXB-79?page=all ]

Alexey Loubyansky closed JBXB-79.
---------------------------------

    Resolution: Done

This issue was fixed as part of the JBXB-76. A test was added to org.jboss.test.xml.ArrayWrapperUnitTestCase.

> Array parameter is being appended rather than passed intact
> -----------------------------------------------------------
>
>                 Key: JBXB-79
>                 URL: http://jira.jboss.com/jira/browse/JBXB-79
>             Project: JBoss XML Binding (JBossXB)
>          Issue Type: Bug
>    Affects Versions: JBossXB-1.0.0.CR6
>            Reporter: David Boeren
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossXB-1.0.0.CR7
>
>         Attachments: coils.ZIP
>
>
> When I call a webservice method and pass an object containing an array of another object type, the server receives the array with additional elements.  The array elements that I pass are appended, so that if I send 1 element the server receives 81.  If  I send 80 elements, the server receives 160.  There are always 80 element preceding the first one that I pass.
> The value 80 comes from code in the object constructor that preinitializes the array to this size.
> This form causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array = new CoilData[80];
> }
> This form likewise causes the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>             array = new CoilData[80];
>         }
> }
> This form does not cause the bug:
> public class Coils implements Serializable{
> 	private int			numberOfCoils;
> 	private CoilData[]	array;
> 	public Coils() {
>         }
> }
> Coils coils = new Coils();
> coils.setArray(new CoilData[80]);
> So, it has something to do with initializing it in the construction of the object.
> Attached is a full Eclipse project exhibiting the bug that you can run on JBoss 4.0.4.GA with JBossWS.
> To keep the attachment size down, I left off the library files.  You will need:
> activation.jar, jbossall-client.jar, jbossws-client.jar, mail.jar, xercesImpl.jar

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 08:40:01 2006
From: jira-events at jboss.com (Dave Caruana (JIRA))
Date: Tue, 26 Sep 2006 08:40:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-756) log.debug calls are
	unprotected
Message-ID: <5660338.1159274401349.JavaMail.jira@cloud.prod.atl2.jboss.com>

log.debug calls are unprotected
-------------------------------

                 Key: JBPM-756
                 URL: http://jira.jboss.com/jira/browse/JBPM-756
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: Window XP, Java 5
            Reporter: Dave Caruana
         Assigned To: Tom Baeyens


Within org.jbpm.context.exe.VariableContainer there are calls to log.debug.  In particular:

line 156:      log.debug("create variable '"+name+"' in '"+this+"' with value '"+value+"'");

line 160:      log.debug("update variable '"+name+"' in '"+this+"' to value '"+value+"'");

However, they are unprotected i.e. the method is called even if debug logging is not switched on.  This is not too much of a problem if the variable value is of a primitive type, but sometimes, values can be complex (including their toString()).

"if (log.isDebugEnabled())" statements are missing.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 08:52:01 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Tue, 26 Sep 2006 08:52:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3601) Switch copyright to
 RedHat Middleware LLC
In-Reply-To: <5022893.1157131903947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11762590.1159275121232.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3601?page=all ]

Dimitris Andreadis closed JBAS-3601.
------------------------------------

    Resolution: Done

The new license header
/*
 * JBoss, Home of Professional Open Source.
 * Copyright 2006, Red Hat Middleware LLC, and individual contributors
 * as indicated by the @author tags. See the copyright.txt file in the
 * distribution for a full listing of individual contributors.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 */

> Switch copyright to RedHat Middleware LLC
> -----------------------------------------
>
>                 Key: JBAS-3601
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3601
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Something like:
> /*
> * JBoss, Home of Professional Open Source
> * Copyright 2006, Red Hat Middleware LLC., and individual contributors as indicated 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 09:01:01 2006
From: jira-events at jboss.com (Vineeth Varghese (JIRA))
Date: Tue, 26 Sep 2006 09:01:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-504) Cannot use the
 object's property named as "attributes" in a rule
Message-ID: <19252356.1159275661477.JavaMail.jira@cloud.prod.atl2.jboss.com>

Cannot use the object's property named as "attributes" in a rule
----------------------------------------------------------------

                 Key: JBRULES-504
                 URL: http://jira.jboss.com/jira/browse/JBRULES-504
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Drl Parser/Builder
    Affects Versions: 3.0.4
         Environment: Windows 2000 with Jdk1.5
            Reporter: Vineeth Varghese
         Assigned To: Mark Proctor
         Attachments: src.zip

The word "attributes" seem to be a keyword in JBoss Rules. Basically if I have an Object that has a property named as "attributes",  I cannot use it in the IDE or create a rulebase out of it. We end up getting the following error:-

org.drools.rule.InvalidRulePackage: unknown:9:19 Unexpected token 'attributes'

	at org.drools.rule.Package.checkValidity(Unknown Source)
	at org.drools.common.AbstractRuleBase.addPackage(Unknown Source)
	at com.sample.DroolsTest.readRule(DroolsTest.java:72)
	at com.sample.DroolsTest.main(DroolsTest.java:23)

Even the IDE highlights this as an error.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 09:07:01 2006
From: jira-events at jboss.com (Dave Caruana (JIRA))
Date: Tue, 26 Sep 2006 09:07:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-757) Constraint violation
 during process deletion
Message-ID: <31944793.1159276021344.JavaMail.jira@cloud.prod.atl2.jboss.com>

Constraint violation during process deletion
--------------------------------------------

                 Key: JBPM-757
                 URL: http://jira.jboss.com/jira/browse/JBPM-757
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: Windows XP, Java 5, MySQL & HSQL.
            Reporter: Dave Caruana
         Assigned To: Tom Baeyens


It's taken a while to pinpoint the exact use-case, however the following test case reproduces the issue.  I don't believe I'm incorrectly using jPDL.

The process has a start task with a task controller that writes a variable (named var1) back to the process.  Note, the process does not have var1 to start with.  Then, a local variable 'var1' is set on the start task instance and the task is ended.  

Please note, at this point, there are VariableInstances persisted without an associated token, tokenvarmap, taskinstance or processinstance.   That's potentially another side-issue, but not core to this particular deletion issue.

The second task 'step2Task' is created (no task controller associated with it).  Now, a new local variable 'var1' is set against this task instance.  The task is ended.

At this point, the process is deleted.  However, it fails with a constraint violation (from FK_VARINST_TKVARMP, in the table "JBPM_VARIABLEINSTANCE" reported in MySQL) or a general exception (reported in HSQL).

Some digging reveals that when the step2Task task instance is ended, all local variables are pushed back to the process.  However, the process already has a var1 as written explicitly by the task controller of the start task.  It seems in TaskInstance.submitVariables, the process var1 is not deleted before the task local variable replaces process variable in the process token variable map.

The following test case demonstrates the issue with the default jbpm configuration files.

import java.util.List;

import junit.framework.TestCase;

import org.jbpm.JbpmConfiguration;
import org.jbpm.JbpmContext;
import org.jbpm.db.GraphSession;
import org.jbpm.db.TaskMgmtSession;
import org.jbpm.graph.def.ProcessDefinition;
import org.jbpm.graph.exe.ProcessInstance;
import org.jbpm.graph.exe.Token;
import org.jbpm.taskmgmt.exe.TaskInstance;


public class JBPMDeleteProcessTest extends TestCase {

    static JbpmConfiguration jbpmConfiguration = null; 
    static long processId = -1L;
    static String currentTokenPath = null;

    static {
      jbpmConfiguration = JbpmConfiguration.parseXmlString(
        "<jbpm-configuration>" +
        "  <jbpm-context>" +
        "    <service name='persistence' " +
        "             factory='org.jbpm.persistence.db.DbPersistenceServiceFactory' />" + 
        "  </jbpm-context>" +
        "  <string name='resource.hibernate.cfg.xml' " +
        "          value='hibernate.cfg.xml' />" +
        "  <string name='resource.business.calendar' " +
        "          value='org/jbpm/calendar/jbpm.business.calendar.properties' />" +
        "  <string name='resource.default.modules' " +
        "          value='org/jbpm/graph/def/jbpm.default.modules.properties' />" +
        "  <string name='resource.converter' " +
        "          value='org/jbpm/db/hibernate/jbpm.converter.properties' />" +
        "  <string name='resource.action.types' " +
        "          value='org/jbpm/graph/action/action.types.xml' />" +
        "  <string name='resource.node.types' " +
        "          value='org/jbpm/graph/node/node.types.xml' />" +
        "  <string name='resource.varmapping' " +
        "          value='org/jbpm/context/exe/jbpm.varmapping.xml' />" +
        "</jbpm-configuration>"
      );
    }
    
    public void setUp() {
      jbpmConfiguration.createSchema();
    }
    
    public void tearDown() {
      jbpmConfiguration.dropSchema();
    }

    public void testDelete() {
      deployProcessDefinition();

      startProcess();
      step2TaskEnd();
      deleteProcess();
    }

    public void deployProcessDefinition() {
      ProcessDefinition processDefinition = ProcessDefinition.parseXmlString
      (
        "<process-definition name='deletetest'>" +
        "  <start-state name='start'> " +  
        "    <task name='startTask'> " +
        "      <controller> " +
        "        <variable name='var1' access='write'/> " +
        "      </controller> " +
        "    </task> " +
        "   <transition name='' to='step2'/> " +
        "  </start-state> " +
        "  <task-node name='step2'> " +
        "    <task name='step2Task'/> " +
        "    <transition name='' to='step3'/> " +
        "  </task-node>" +
        "  <task-node name='step3'> " +
        "    <task name='step3Task'/> " +
        "    <transition name='' to='end'/> " +
        "  </task-node> " +      
        "  <end-state name='end' />" +
        "</process-definition>"
      );
      
      JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
      try {
        jbpmContext.deployProcessDefinition(processDefinition);
      } finally {
        jbpmContext.close();
      }
    }

    public void startProcess() {

      JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
      try {

        GraphSession graphSession = jbpmContext.getGraphSession();
        
        ProcessDefinition processDefinition = graphSession.findLatestProcessDefinition("deletetest");
        ProcessInstance processInstance = new ProcessInstance(processDefinition);
        processId = processInstance.getId();

        TaskInstance taskInstance = processInstance.getTaskMgmtInstance().createStartTaskInstance();
        taskInstance.setVariableLocally("var1", "var1Value");
        taskInstance.end();
        Token token = taskInstance.getToken();
        currentTokenPath = token.getFullName();
        
        jbpmContext.save(processInstance);
      } finally {
        jbpmContext.close();
      }
    }

    public void step2TaskEnd() {

        JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
        try {

          GraphSession graphSession = jbpmContext.getGraphSession();
          ProcessInstance processInstance = graphSession.loadProcessInstance(processId);
          Token token = processInstance.findToken(currentTokenPath);
          TaskMgmtSession taskSession = jbpmContext.getTaskMgmtSession();
          List tasks = taskSession.findTaskInstancesByToken(token.getId());
          TaskInstance taskInstance = (TaskInstance)tasks.get(0);

          //
          // comment out the following line and it works
          //
          taskInstance.setVariableLocally("var1", "var1TaskValue");

          taskInstance.setVariableLocally("var2", "var2UpdatedValue");
          taskInstance.end();
          token = taskInstance.getToken();
          currentTokenPath = token.getFullName();
          
          jbpmContext.save(processInstance);
        } finally {
          jbpmContext.close();
        }
      }

    
    public void deleteProcess()
    {
        JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext();
        try {

          GraphSession graphSession = jbpmContext.getGraphSession();
          ProcessInstance processInstance = graphSession.loadProcessInstance(processId);
          graphSession.deleteProcessInstance(processInstance, true, true, true);
          //jbpmContext.save(processInstance);
        } finally {
          jbpmContext.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

        


From jira-events at jboss.com  Tue Sep 26 09:37:01 2006
From: jira-events at jboss.com (Remy Maucherat (JIRA))
Date: Tue, 26 Sep 2006 09:37:01 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3350) NPE on web service
	deployment
Message-ID: <30766120.1159277821131.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3350?page=all ]

Remy Maucherat resolved JBAS-3350.
----------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta
       Resolution: Done

Ok. I may remove that naming code in the future.

> NPE on web service deployment
> -----------------------------
>
>                 Key: JBAS-3350
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3350
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Thomas Diesler
>         Assigned To: Remy Maucherat
>             Fix For: JBossAS-5.0.0.Beta
>
>
> tdiesler at TDDELL /cygdrive/d/svn/jbossws/trunk/src/test
> $ ant -Dtest=org.jboss.test.ws.wsse.WebClientTestCase one-test
> 2006-06-29 11:02:35,953 ERROR [org.apache.catalina.startup.ContextConfig] Parse error in application web.xml file at jndi:/localhost/jbossws-wsse-rpc/WEB-INF/web.xml
> java.lang.NullPointerException
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2725)
> 	at org.apache.tomcat.util.digester.Digester.createSAXException(Digester.java:2751)
> 	at org.apache.tomcat.util.digester.Digester.endElement(Digester.java:1060)
> 	at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
> <web-app version='2.4' xmlns='http://java.sun.com/xml/ns/j2ee' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd'>
>  <servlet>
>   <servlet-name>Hello</servlet-name>
>   <servlet-class>org.jboss.ws.integration.jboss.JBossServiceEndpointServlet</servlet-class>
>   <init-param>
>    <param-name>ServiceEndpointImpl</param-name>
>    <param-value>org.jboss.test.ws.wsse.HelloJavaBean</param-value>
>   </init-param>
>  </servlet>
>  <servlet>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <servlet-class>org.jboss.test.ws.wsse.RpcTestClientServlet</servlet-class>
>  </servlet>
>  <servlet-mapping>
>   <servlet-name>Hello</servlet-name>
>   <url-pattern>/Hello</url-pattern>
>  </servlet-mapping>
>  <servlet-mapping>
>   <servlet-name>RpcTestClientServlet</servlet-name>
>   <url-pattern>/RpcTestClientServlet</url-pattern>
>  </servlet-mapping>
>  <service-ref>
>   <service-ref-name>service/HelloService</service-ref-name>
>   <service-interface>javax.xml.rpc.Service</service-interface>
>   <wsdl-file>WEB-INF/wsdl/HelloService.wsdl</wsdl-file>
>   <jaxrpc-mapping-file>WEB-INF/jaxrpc-mapping.xml</jaxrpc-mapping-file>
>   <port-component-ref>
>    <service-endpoint-interface>org.jboss.test.ws.wsse.Hello</service-endpoint-interface>
>   </port-component-ref>
>  </service-ref>
> </web-app>

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 09:54:40 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Tue, 26 Sep 2006 09:54:40 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-601) Integrate http with
	messaging
In-Reply-To: <14467485.1158813717043.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26602327.1159278880219.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-601?page=all ]

Tom  Elrod updated JBREM-601:
-----------------------------

    Assignee: Ron Sigal  (was: Tom  Elrod)

> Integrate http with messaging
> -----------------------------
>
>                 Key: JBREM-601
>                 URL: http://jira.jboss.com/jira/browse/JBREM-601
>             Project: JBoss Remoting
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.0.Beta1 (Bluto)
>            Reporter: Ron Sigal
>         Assigned To: Ron Sigal
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> A few changes need to be made for the http transport to work with JBossMessaging.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:17:42 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 10:17:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-777) Creating a custom
 cache loader
 which delegates to a standard cache loader, can generate misleading WARN
 messages
In-Reply-To: <2180247.1158932521626.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1950446.1159280262780.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-777?page=all ]

Galder Zamarreno resolved JBCACHE-777.
--------------------------------------

    Resolution: Done

The level of the CacheLoader WARN message (when using custom) regarding new CacheLoader contract has changed to INFO. The message is still needed for customers to be aware of the CacheLoader interface contract changes added with JBC 1.3.

> Creating a custom cache loader which delegates to a standard cache loader, can generate misleading WARN messages
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: JBCACHE-777
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-777
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1, 1.3.0.SP3
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: 1.4.0.SP2
>
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>
> FileCacheLoader can return a null value for get(fqn) if the node does not exist.
>  /**
>     * Returns all keys and values from the persistent store, given a fully qualified name.
>     *
>     * NOTE that the expected return value of this method has changed from JBossCache 1.2.x
>     * and before!  This will affect cache loaders written prior to JBossCache 1.3.0 and such
>     * implementations should be checked for compliance with the behaviour expected.
>     *
>     * @param name
>     * @return Map<Object,Object> keys and values for the given node. Returns
>     * null if the node is not found.  If the node is found but has no
>     * attributes, this method returns an empty Map.
>     * @throws Exception
>  */
> If the customer creates a custom cache loader which delegates to a FileCacheLoader, the 
> following misleading warning message is logged:
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get(Fqn) returned a null; assuming the node nodes not exist.
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] The CacheLoader interface has changed since JBossCache 1.3.x
> 10:52:10.839 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] Please see http://jira.jboss.com/jira/browse/JBCACHE-118
> 10:52:10.849 WARN [MessageListenerThread - Belvedere/Desk/CacheLoaderInterceptor] CacheLoader.get() should return an empty Map if the node does exist but doesn't have any attributes.
> This occurrs even though the FileCacheLoader is actually doing the job accordingly.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:29:41 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 10:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-786) errors from "OK"
 putFailFast replications
Message-ID: <1399685.1159280981956.JavaMail.jira@cloud.prod.atl2.jboss.com>

errors from "OK" putFailFast replications
-----------------------------------------

                 Key: JBCACHE-786
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-786
             Project: JBoss Cache
          Issue Type: Patch
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0.SP1
            Reporter: Owen Taylor
         Assigned To: Manik Surtani
            Priority: Optional
         Attachments: jbosscache-failfast-replicate-failure.patch

[ Although putFailFast() is deprecated, it is still used by current versions of Hibernate ]

With putFailFast(), you fairly frequently see the following situation:
 
 - a call to putFailFast() succeeds
 - the (asynchronous) replication fails due to a lock timeout, and throws an exception t
   that  is thrown is logged at level ERROR

(Much more frequently because of JBCACHE-785, but it is a legitimate situation that
doesn't indicate an error.)

This patch simply detects that case and suppresses the warning. (You might be able to
it more elegantly by bridging putFailFast() onto the options framework, but to get the
exact existing behavior of putFailFast() would take a fairly extensive patch.)



-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:29:42 2006
From: jira-events at jboss.com (Owen Taylor (JIRA))
Date: Tue, 26 Sep 2006 10:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-786) errors from "OK"
 putFailFast replications
In-Reply-To: <1399685.1159280981956.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22927280.1159280982208.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-786?page=all ]

Owen Taylor updated JBCACHE-786:
--------------------------------

    Attachment: jbosscache-failfast-replicate-failure.patch

> errors from "OK" putFailFast replications
> -----------------------------------------
>
>                 Key: JBCACHE-786
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-786
>             Project: JBoss Cache
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.SP1
>            Reporter: Owen Taylor
>         Assigned To: Manik Surtani
>            Priority: Optional
>         Attachments: jbosscache-failfast-replicate-failure.patch
>
>
> [ Although putFailFast() is deprecated, it is still used by current versions of Hibernate ]
> With putFailFast(), you fairly frequently see the following situation:
>  
>  - a call to putFailFast() succeeds
>  - the (asynchronous) replication fails due to a lock timeout, and throws an exception t
>    that  is thrown is logged at level ERROR
> (Much more frequently because of JBCACHE-785, but it is a legitimate situation that
> doesn't indicate an error.)
> This patch simply detects that case and suppresses the warning. (You might be able to
> it more elegantly by bridging putFailFast() onto the options framework, but to get the
> exact existing behavior of putFailFast() would take a fairly extensive patch.)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:35:41 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 26 Sep 2006 10:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-787) Documentation: Add
 a chapter on extending JBoss Cache
Message-ID: <5188557.1159281341556.JavaMail.jira@cloud.prod.atl2.jboss.com>

Documentation: Add a chapter on extending JBoss Cache
-----------------------------------------------------

                 Key: JBCACHE-787
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-787
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.0.0


With sections on:

  1) The SPI interface
  2) How to write your custom cache loader
  3) How to write your custom eviction policy
  4) How to write your custom transaction manager lookup
  5) How to write your custom cache listener

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 10:38:41 2006
From: jira-events at jboss.com (Manik Surtani (JIRA))
Date: Tue, 26 Sep 2006 10:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-788) Optimistic locking
 should not REQUIRE transactions!
Message-ID: <27121247.1159281521408.JavaMail.jira@cloud.prod.atl2.jboss.com>

Optimistic locking should not REQUIRE transactions!
---------------------------------------------------

                 Key: JBCACHE-788
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-788
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.0, 1.3.0, 2.0.0
            Reporter: Manik Surtani
         Assigned To: Manik Surtani
             Fix For: 2.1.0


Makes things simpler.

TXs are only used so transaction workspaces can be stored in a transaction entry.  This workspace can just as easily be stored in ThreadLocal for non-tx calls (that just have the lifespan of a single invocation).

This will:

1) Make things a LOT quicker since we don't need 2PC for all calls.
2) Make the TxInterceptor a lot simpler
3) Allow the use of Opt Locking without a TM

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 12:16:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Tue, 26 Sep 2006 12:16:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3701)
 SystemPropertiesService does not
 properly generate server path on windows
Message-ID: <32333943.1159287401584.JavaMail.jira@cloud.prod.atl2.jboss.com>

SystemPropertiesService does not properly generate server path on windows
-------------------------------------------------------------------------

                 Key: JBAS-3701
                 URL: http://jira.jboss.com/jira/browse/JBAS-3701
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Anil Saldhana
             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1


  <mbean code="org.jboss.varia.property.SystemPropertiesService"
    name="jboss:type=Service,name=SystemProperties">
    <attribute name="Properties" replace="false"> 
         log.file.location=${jboss.server.home.dir}/log 
    </attribute>
  </mbean>

The jboss.server.home.dir is not string replaced properly on windows.

I suspect it to be related to the Property class in the Jboss common module.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 12:59:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 26 Sep 2006 12:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-557) Possible
 failure to correctly recover persistent messages on crash
Message-ID: <27405237.1159289981627.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible failure to correctly recover persistent messages on crash
------------------------------------------------------------------

                 Key: JBMESSAGING-557
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-557
             Project: JBoss Messaging
          Issue Type: Bug
          Components: Messaging Core Persistence
    Affects Versions: 1.0.1.CR5, 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Beta1


Created based a forum report that describes failure to correctly recover persistent messages after server failure.
Need to create a specialized test and investigate.
Forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974282

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 13:02:41 2006
From: jira-events at jboss.com (jasonc411 (JIRA))
Date: Tue, 26 Sep 2006 13:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-503) Compiler
 Throwing an exception on generics
In-Reply-To: <23708343.1159199821228.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16710806.1159290161943.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-503?page=comments#action_12344054 ] 
            
jasonc411 commented on JBRULES-503:
-----------------------------------

So, I found the problem, and it was with the code in the save method.  What I did find is that compiler errors are not being displayed in the console output when the they are encountered.  The compilation errors are not being displayed just a message saying that an unspecified exception was caught, I had put some debugging println s in the method collectCompilerProblems and found the problem.  That though looks to be a bug in itself.

We can close this bug and reopen another that is more specific to the real problem of compiler errors not being dumped to the console or reported as part of the exception. This affects both the eclipse plugin and the PackageBuilder users.

> Compiler Throwing an exception on generics
> ------------------------------------------
>
>                 Key: JBRULES-503
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-503
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Drl Parser/Builder
>    Affects Versions: 3.0.4
>         Environment: JBoss Rules 3.0.4, antlr-2.7.6.jar, antlr-3.0ea8.jar, commons-jci-core-1.0-406301.jar, commons-jci-eclipse-3.2.0.666.jar, core-3.2.0.666.jar, drools-compiler-3.0.4.jar, drools-jsr94-3.0.4.jar, jsr94-1.1.jar, stringtemplate2.3b6.jar
>            Reporter: jasonc411
>         Assigned To: Mark Proctor
>
> #created on: Sep 15, 2006
> package com.ca.data.dsrules
> #list any import classes here.
> import com.ca.data.model.base.DataSourceEnum;
> import com.ca.data.model.issuer.Issuer;
> import java.util.ArrayList;
> import java.util.List;
> import com.ca.data.model.Data;
> import com.ca.data.datasubs.utils.JMSServiceLocator;
> import com.ca.data.jms.JMSTextMessageSender;
> function void save(Issuer issuer){
> 	JMSTextMessageSender cleanQueue = JMSServiceLocator.getTextSender("SomeServer", "SomeTopic");
> 	Data data = new Data();
> 	List<Issuer> myIssuers = new ArrayList<Issuer>();
> 	myIssuers.add(issuer);
> 	
> 	Data.setIssuerList(myIssuers);
> 	
> 	cleanQueue.simpleSend(issuer);
> }
> rule "Persist Validated Data"
> 	agenda-group "Data In"
> 	no loop
> 	salience 1
> 	
> 	when
> 		issuer : Issuer(dataSource == DataSourceEnum.SomeSource, id != -1)
> 	then 
> 		System.out.println("Validated");
> 		save(issuer);
> end

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 13:35:44 2006
From: jira-events at jboss.com (Mark Menard (JIRA))
Date: Tue, 26 Sep 2006 13:35:44 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-553) PrePersist
 callback method not called if entity's primery key is null
Message-ID: <13408433.1159292144943.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-553?page=all ]

Mark Menard updated EJBTHREE-553:
---------------------------------

    Attachment: EJB3EventListener_v2.patch

This is an updated patch based on Michal's work. This patch is against hibernate-entitymanager-3.2.20.CR2.

> PrePersist callback method not called if entity's primery key is null
> ---------------------------------------------------------------------
>
>                 Key: EJBTHREE-553
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-553
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jboss-4.0.4.CR2
>            Reporter: Michal Borowiecki
>         Attachments: EJB3EventListener_v2.patch
>
>
> When an entity is persisted which does not have its primary key set (and it is not annotated with GeneratedValue annotation), the @PrePersist callback method is not invoked. 
> Instead the exception is thrown:
> Caused by: org.hibernate.id.IdentifierGenerationException: ids for this class must be manually assigned before calling save(): com.bluemedia.system.User
> 	at org.hibernate.id.Assigned.generate(Assigned.java:33)
> 	at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:98)
> 	at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
> 	at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
> 	at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:617)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:591)
> 	at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:595)
> 	at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:187)
> 	... 64 more
> This is in conflict with ejb 3.0-pfd spec, which states (sec. 3.4.2) :
> "The PrePersist and PreRemove callback methods are invoked for a given entity before the respective EntityManager persist and remove operations for that entity are executed."
> Since the spec states that EntityManager's persist operation is executed after the PrePersist callback methods, setting the value of the primary key in a PrePersist callback method seems a reasonable use case.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:08:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 26 Sep 2006 14:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-558) Possible
 performance
 degradation relative to JBossMQ when using contested queues and selectors
Message-ID: <527286.1159294121642.JavaMail.jira@cloud.prod.atl2.jboss.com>

Possible performance degradation relative to JBossMQ when using contested queues and selectors
----------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-558
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-558
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR5, 1.0.1.CR4
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Beta1


Problem described on the forum: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91326

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:17:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 14:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
Message-ID: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>

Uncomment HA invokers in sample-bindings.xml
--------------------------------------------

                 Key: JBAS-3702
                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
            Reporter: Galder Zamarreno
         Assigned To: Galder Zamarreno
             Fix For: JBossAS-4.0.5.GA


Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:17:42 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Tue, 26 Sep 2006 14:17:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12160486.1159294662088.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3702?page=all ]

Galder Zamarreno updated JBAS-3702:
-----------------------------------

    Priority: Minor  (was: Major)

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:26:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Tue, 26 Sep 2006 14:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-559) Add a
 4.0.5.CR1 EJB3 smoke test
Message-ID: <31350343.1159295201477.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a 4.0.5.CR1 EJB3 smoke test
-------------------------------

                 Key: JBMESSAGING-559
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-559
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.0.1.CR6




-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:45:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-364) Use reflection in
 org.jboss.seam.util.Persistence
In-Reply-To: <20736586.1159029241179.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8673930.1159296341790.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-364?page=all ]

Gavin King updated JBSEAM-364:
------------------------------

    Fix Version/s: 1.1
         Assignee: Gavin King

> Use reflection in org.jboss.seam.util.Persistence
> -------------------------------------------------
>
>                 Key: JBSEAM-364
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-364
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> Currently we got a hard dependence to Hibernate. We should use reflection in this class.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:47:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-332) javabeans in
 session are not distributable
In-Reply-To: <13441536.1155654861191.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23586587.1159296461884.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-332?page=all ]

Gavin King updated JBSEAM-332:
------------------------------

    Fix Version/s: 1.1

> javabeans in session are not distributable
> ------------------------------------------
>
>                 Key: JBSEAM-332
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-332
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0, JBoss 4.0.4GA, Windows Server 2003, Cluster of 4 nodes on 2 machines.
>            Reporter: Keith Naas
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>         Attachments: itpa.ear, itpa.ear
>
>
> We have an application that makes use of JavaBeans for a lot of our JSF "actions".  When one of our nodes is brought down, the session should Seamlessly failover to another node.  The user is sent  to a different node, but the entire session appears to be in a clean state.   We looked through the server logs and saw the following:
> 2006-08-15 10:47:36,658 ERROR [org.jboss.web.tomcat.tc5.session.JBossCacheService] [.......] loadSession(): id: GWrcdSJEASvXSJnX6fNHNg**exception occurred during serialization: java.lang.ClassNotFoundException: No ClassLoaders found for: com.ourapp.web.beans.WorksheetBean$$EnhancerByCGLIB$$bf40374c
> All of our beans are Serializable, but it appears that there is an issue with the cache sync of the CGLib proxy classes.  This specific bean does have some service properties that are transients.  It also has properties that refer to other Web JavaBeans.  
> We will be investigating this some more, but we wanted to get this logged since it appears to be a major issue that prevents us from clustering our Seam apps.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:56:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-335)
 NullPointerException if user
 quikcly decides to click a different link or button before the page renders
In-Reply-To: <7270828.1155764675359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15721507.1159297001549.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-335?page=all ]

Gavin King updated JBSEAM-335:
------------------------------

    Component/s: Core

> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-335
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-335
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
>            Reporter: Keith Naas
>            Priority: Critical
>             Fix For: 1.1
>
>
> When a user is on one of our screens, they can decide to click a link before the next page loads.  Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181.  Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().  
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.  
> Stack Trace
> java.lang.NullPointerException
> 	at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> 	at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> 	at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> 	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> .....

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 14:56:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-335)
 NullPointerException if user
 quikcly decides to click a different link or button before the page renders
In-Reply-To: <7270828.1155764675359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11240042.1159297001778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-335?page=all ]

Gavin King updated JBSEAM-335:
------------------------------

    Fix Version/s: 1.1
         Assignee: Gavin King

> NullPointerException if user quikcly decides to click a different link or button before the page renders
> --------------------------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-335
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-335
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: Core
>         Environment: Seam 1.0.1.GA. JBoss 4.0.4, Windows XP, Facelets, MyFaces, Hibernate
>            Reporter: Keith Naas
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> When a user is on one of our screens, they can decide to click a link before the next page loads.  Sometimes, when this do this quickly enough, it causes a NullPointerException in Manager.touchConversationStack at line 181.  Somehow, the currentConversationEntry is null and it breaks when it executes getCurrentConversationEntry().touch().  
> I tried unsuccessfully to duplicate this scenario on the Hotel and DVD Store demos hosted on JBoss.  
> Stack Trace
> java.lang.NullPointerException
> 	at org.jboss.seam.core.Manager.touchConversationStack(Manager.java:181)
> 	at org.jboss.seam.core.Manager.storeConversation(Manager.java:368)
> 	at org.jboss.seam.jsf.AbstractSeamPhaseListener.storeAnyConversationContext(AbstractSeamPhaseListener.java:69)
> 	at org.jboss.seam.jsf.SeamStateManager.saveSerializedView(SeamStateManager.java:45)
> 	at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:578)
> 	at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:384)
> 	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:138)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> .....

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 15:05:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 15:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3703) Update JRMPInvoker
 to not cast exported object to RemoteStub
Message-ID: <13172185.1159297541691.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update JRMPInvoker to not cast exported object to RemoteStub
------------------------------------------------------------

                 Key: JBAS-3703
                 URL: http://jira.jboss.com/jira/browse/JBAS-3703
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Remoting
    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1
            Reporter: Scott M Stark
         Assigned To: Tom  Elrod
             Fix For: JBossAS-4.0.6.CR1


If one runs with the jdk5 java.rmi.server.ignoreStubClasses dynamic stub override to force the server to generate stubs for exported objects, the JRMPInvoker fails to start with the following exception:

[starksm at succubus bin]$ run.sh -D-Djava.rmi.server.ignoreStubClasses=true
=========================================================================

...

11:55:52,477 WARN  [ServiceController] Problem starting service jboss:service=invoker,type=jrmp
java.lang.ClassCastException: $Proxy13
        at org.jboss.invocation.jrmp.server.JRMPInvoker.exportCI(JRMPInvoker.java:437)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.startService(JRMPInvoker.java:359)
        at org.jboss.invocation.jrmp.server.JRMPInvoker$1.startService(JRMPInvoker.java:136)
        at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)

The reason is that the code creating the remote object is explictly casting the export result to a RemoteStub:

   protected void exportCI() throws Exception
   {
      this.invokerStub = (RemoteStub) UnicastRemoteObject.exportObject
         (this, rmiPort, clientSocketFactory, serverSocketFactory);
   }

even though the public contract for this stub only requires a Serializable instance. The type of the invokerStub should just be relaxed to Serializable.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 15:11:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 15:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-365) <import> in
	components.xml
Message-ID: <9866704.1159297901635.JavaMail.jira@cloud.prod.atl2.jboss.com>

<import> in components.xml
--------------------------

                 Key: JBSEAM-365
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-365
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


I hate how all the built-in components have no namespace. Lets put them all back in org.jboss.seam.core, and allow use of <import namespace="org.jboss.seam.core"/> in components.xml.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 15:42:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 15:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3704) Add a notion of
 available interfaces to org.jboss.test.util.server.*
Message-ID: <18012080.1159299761464.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a notion of available interfaces to org.jboss.test.util.server.*
--------------------------------------------------------------------

                 Key: JBAS-3704
                 URL: http://jira.jboss.com/jira/browse/JBAS-3704
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Test Suite
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
             Fix For: JBossAS-4.0.6.CR1


An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces.

We need to add this functionality to the server startup tasks.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:18:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-108) Migrate all of
 the JBoss.com Forums data to this new Forums
In-Reply-To: <19103345.1153928592271.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26846209.1159301921874.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-108?page=all ]

Ryszard Kozmik updated JBFORUMS-108:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Migrate all of the JBoss.com Forums data to this new Forums
> -----------------------------------------------------------
>
>                 Key: JBFORUMS-108
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-108
>             Project: JBoss Forums
>          Issue Type: Sub-task
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:18:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:18:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-106) Load it on a
 server for Beta Testing
In-Reply-To: <977450.1153928591749.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24348436.1159301922097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-106?page=all ]

Ryszard Kozmik updated JBFORUMS-106:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Load it on a server for Beta Testing
> ------------------------------------
>
>                 Key: JBFORUMS-106
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-106
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Java Server Faces based UIController layer
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-126) NewTopic on
 ForumsView doesn't work on IE
In-Reply-To: <7318128.1159042381055.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3468292.1159302102077.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-126?page=all ]

Ryszard Kozmik updated JBFORUMS-126:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> NewTopic on ForumsView doesn't work on IE
> -----------------------------------------
>
>                 Key: JBFORUMS-126
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-126
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Beta
>
>
> Creating topic by NewTopic button on ForumsView is not possible when browsing Forums using IE.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-83) Write User and
 Administration Guide
Message-ID: <31171798.1159302102240.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-83?page=all ]

Ryszard Kozmik updated JBFORUMS-83:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Write User and Administration Guide
> -----------------------------------
>
>                 Key: JBFORUMS-83
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-83
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Documentation, Portlet Productization
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Damon Sicore
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> Create and write a JBoss Forums User and Admin Guide.
> I suspect we only need to combine the Admin and User guide into one due to the size of this project (i.e., it's small).
> Specifically:
> * JBoss Forums Deployment Packaging.
> * Deployment Steps
> * User Administration
> * Forum and Topic Administration
> * Security and Spam
> * Forum and Topic User Instructions

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-92) UTF-8 doesn't work
 in topic subjects
Message-ID: <28369045.1159302102786.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-92?page=all ]

Ryszard Kozmik updated JBFORUMS-92:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> UTF-8 doesn't work in topic subjects
> ------------------------------------
>
>                 Key: JBFORUMS-92
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-92
>             Project: JBoss Forums
>          Issue Type: Bug
>            Reporter: Tomasz Szymanski
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> http://65.244.175.213:8080/portal-forums/views/index.jsf
> shows some silly chars instead of polish diacritic letters.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:42 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-103) Try to fix the
 followind issue
 in http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3959142#3959142
In-Reply-To: <30458909.1153317971362.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15950960.1159302102915.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-103?page=all ]

Ryszard Kozmik updated JBFORUMS-103:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Try to fix the followind issue in http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3959142#3959142
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: JBFORUMS-103
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-103
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Sohil Shah
>         Assigned To: Sohil Shah
>             Fix For: 1.0.0 Beta
>
>
> Seems like there are special characters in the post that are messing up the post display on the forums in JBoss.com
> Funny this if there was an issue with the code parser there would be a problem of showing the posts even in the post reply screen, but that screen is fine.
> Need to make sure this same error does not crop up in the new Forums

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-84) Package and Add to
	Portlet Swap
Message-ID: <23252225.1159302103070.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-84?page=all ]

Ryszard Kozmik updated JBFORUMS-84:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Package and Add to Portlet Swap
> -------------------------------
>
>                 Key: JBFORUMS-84
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-84
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Portlet Productization
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Damon Sicore
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> Add JBoss Forums to Portlet Swap.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-115) NPE in ViewTopic
In-Reply-To: <1960202.1154560871633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25451023.1159302103273.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-115?page=all ]

Ryszard Kozmik updated JBFORUMS-115:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> NPE in ViewTopic
> ----------------
>
>                 Key: JBFORUMS-115
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-115
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>          Time Spent: 2 hours, 30 minutes
>
> Clicking this link http://forums.proto.jboss.com:8080/portal/index.html?ctrl:cmd=render&ctrl:window=default.default.DefaultCMSPortletWindow&t=12&org.apache.myfaces.portlet.MyFacesGenericPortlet.VIEW_ID=%2Fviews%2Ftopics%2Fviewtopic_body.jsf , causes whole forums to dissapear and throw this exception:
> 18:06:20,855 ERROR [[/portal-forums]] Exception in FacesServlet
> java.lang.NullPointerException
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.facesRender(MyFacesGenericPortlet.java:393)
>         at org.apache.myfaces.portlet.MyFacesGenericPortlet.doView(MyFacesGenericPortlet.java:266)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.doView(ForumsJSFPortlet.java:94)
>         at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:167)
>         at javax.portlet.GenericPortlet.render(GenericPortlet.java:407)
>         at org.jboss.portlet.forums.ui.ForumsJSFPortlet.render(ForumsJSFPortlet.java:128)
>         at org.jboss.portal.portlet.PortletContainer.invokeRender(PortletContainer.java:521)
>         at org.jboss.portal.portlet.PortletContainer.dispatch(PortletContainer.java:433)
>         at org.jboss.portal.server.app.ComponentInvocation.dispatch(ComponentInvocation.java:79)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.component.TransactionInterceptor.invoke(TransactionInterceptor.java:72)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.component.HeaderInterceptor.invoke(HeaderInterceptor.java:50)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.NavigationInterceptor.invoke(NavigationInterceptor.java:76)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.CacheInterceptor.invoke(CacheInterceptor.java:111)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ModesInterceptor.invoke(ModesInterceptor.java:88)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.WindowStatesInterceptor.invoke(WindowStatesInterceptor.java:87)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPostDispatchInterceptor.invoke(SessionPostDispatchInterceptor.java:65)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$InvokeNextCommand.execute(ContextDispatcherInterceptor.java:129)
>         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.jboss.portal.server.servlet.CommandServlet.doGet(CommandServlet.java:101)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>         at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:539)
>         at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>         at org.jboss.portal.server.app.impl.AbstractRequestContext.include(AbstractRequestContext.java:247)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor$1.include(ContextDispatcherInterceptor.java:73)
>         at org.jboss.portal.server.servlet.CommandServlet.include(CommandServlet.java:81)
>         at org.jboss.portal.server.aspects.component.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:79)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SessionPreDispatchInterceptor.invoke(SessionPreDispatchInterceptor.java:94)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.component.ContextTrackerInterceptor.invoke(ContextTrackerInterceptor.java:49)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.portlet.aspects.component.ValveInterceptor.invoke(ValveInterceptor.java:64)
>         at org.jboss.portal.server.app.ComponentInterceptor.invoke(ComponentInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.RenderWindowCommand.execute(RenderWindowCommand.java:84)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:68)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.CommandContext.chain(CommandContext.java:141)
>         at org.jboss.portal.core.command.RenderPageCommand.renderPortlets(RenderPageCommand.java:231)
>         at org.jboss.portal.core.command.RenderPageCommand.execute(RenderPageCommand.java:164)
>         at org.jboss.portal.core.command.ControllerCommand.dispatch(ControllerCommand.java:78)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.controller.EventBroadcasterInterceptor.invoke(EventBroadcasterInterceptor.java:85)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PolicyEnforcementInterceptor.invoke(PolicyEnforcementInterceptor.java:168)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.PortalNodeInterceptor.invoke(PortalNodeInterceptor.java:61)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.controller.NavigationInterceptor.invoke(NavigationInterceptor.java:58)
>         at org.jboss.portal.core.command.CommandInterceptor.invoke(CommandInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.core.command.CommandContext.execute(CommandContext.java:107)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:93)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:151)
>         at org.jboss.portal.core.command.ExecutionContext.execute(ExecutionContext.java:77)
>         at org.jboss.portal.core.CoreController.handle(CoreController.java:190)
>         at sun.reflect.GeneratedMethodAccessor310.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.mx.util.JMXInvocationHandler.invoke(JMXInvocationHandler.java:273)
>         at $Proxy136.handle(Unknown Source)
>         at org.jboss.portal.server.ServerInvocation.dispatch(ServerInvocation.java:76)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:140)
>         at org.jboss.portal.core.aspects.server.SubjectAssociationInterceptor.invoke(SubjectAssociationInterceptor.java:47)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.PolicyAssociationInterceptor.invoke(PolicyAssociationInterceptor.java:52)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.ContentTypeInterceptor.invoke(ContentTypeInterceptor.java:68)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.LocaleInterceptor.invoke(LocaleInterceptor.java:69)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.UserInterceptor.invoke(UserInterceptor.java:184)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.aspects.server.SessionInvalidatorInterceptor.invoke(SessionInvalidatorInterceptor.java:87)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.core.aspects.server.TransactionInterceptor.invoke(TransactionInterceptor.java:75)
>         at org.jboss.portal.server.ServerInterceptor.invoke(ServerInterceptor.java:38)
>         at org.jboss.portal.server.invocation.Invocation.invokeNext(Invocation.java:130)
>         at org.jboss.portal.server.invocation.Invocation.invoke(Invocation.java:175)
>         at org.jboss.portal.server.servlet.PortalServlet.doGet(PortalServlet.java:221)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:21:43 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:21:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-119) Links to last
 post on all views are not working correctly
In-Reply-To: <30379171.1157039900135.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24666659.1159302103438.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-119?page=all ]

Ryszard Kozmik updated JBFORUMS-119:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Links to last post on all views are not working correctly
> ---------------------------------------------------------
>
>                 Key: JBFORUMS-119
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-119
>             Project: JBoss Forums
>          Issue Type: Bug
>          Components: Java Server Faces based UIController layer
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> All links to last post do not care about paging. So, if there is more than one page in TopicView then Last Post links are pointing wrongly always to first page not to the page containing this post. Moreover permament link to post on TopicView is too long and must be shortened plus must care about paging too.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:24:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-85) Identify and
 Define Training Materials for Portal Training
Message-ID: <6318516.1159302281609.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-85?page=all ]

Ryszard Kozmik updated JBFORUMS-85:
-----------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> Identify and Define Training Materials for Portal Training
> ----------------------------------------------------------
>
>                 Key: JBFORUMS-85
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-85
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Documentation, Portlet Productization
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Damon Sicore
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.0.0 Beta
>
>
> At a minimum, we need to at least identify the relationships with JBoss Portal training and where JBoss Forums administration and usage concepts are required.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:24:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 16:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBFORUMS-123) On preview topic
 view "Powered by JBoss Portal" tag flies around
In-Reply-To: <4351983.1159037881234.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23199987.1159302281759.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-123?page=all ]

Ryszard Kozmik updated JBFORUMS-123:
------------------------------------

    Fix Version/s: 1.0.0 Beta
                       (was: 1.0.0 Alpha)

Moving to 1.0.0 Beta Release

> On preview topic view "Powered by JBoss Portal" tag flies around
> ----------------------------------------------------------------
>
>                 Key: JBFORUMS-123
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-123
>             Project: JBoss Forums
>          Issue Type: Bug
>    Affects Versions: 1.0.0 Alpha
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.0.0 Beta
>
>
> While creating topic with preview the theme tag "Powered by JBoss Portal / Theme by ***" flies over forums.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:30:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 16:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-134) Update the property
	manager xsd
Message-ID: <16916820.1159302641456.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update the property manager xsd
-------------------------------

                 Key: JBTM-134
                 URL: http://jira.jboss.com/jira/browse/JBTM-134
             Project: JBoss Transaction Manager
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Release
            Reporter: Mark Little
         Assigned To: Mark Little


The schemas for the property manager are out of date.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 16:33:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Tue, 26 Sep 2006 16:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBTM-92) Print error message
 when prepare fails in XAResource
Message-ID: <7422398.1159302821708.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-92?page=all ]

Mark Little reassigned JBTM-92:
-------------------------------

    Assignee: Mark Little  (was: Jonathan Halliday)

> 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.4
>
>
> 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

        


From jira-events at jboss.com  Tue Sep 26 18:21:41 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Tue, 26 Sep 2006 18:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-560) Support all
 JBossMQ equivalent JMX functionality
Message-ID: <12497178.1159309301592.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support all JBossMQ equivalent JMX functionality
------------------------------------------------

                 Key: JBMESSAGING-560
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-560
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Tim Fox
             Fix For: 1.2.0.Beta1


For 1.2 we need to ensure we support the same or equivalent set of management functionality as JBoss MQ.




-- 
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

        


From jira-events at jboss.com  Tue Sep 26 18:42:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 18:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3705) Fixes included in
 JBAS-3689 for
 allowing the NamingService to work correctly in multi-homed environments
 need to be incorporated.
Message-ID: <11299157.1159310561613.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 
----------------------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3705
                 URL: http://jira.jboss.com/jira/browse/JBAS-3705
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA


Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 18:48:41 2006
From: jira-events at jboss.com (Ryszard Kozmik (JIRA))
Date: Tue, 26 Sep 2006 18:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-130) Add JBoss Forums
 to Portal demo.
Message-ID: <21653339.1159310921646.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add JBoss Forums to Portal demo.
--------------------------------

                 Key: JBFORUMS-130
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-130
             Project: JBoss Forums
          Issue Type: Task
            Reporter: Ryszard Kozmik
         Assigned To: Roy Russo
            Priority: Minor
             Fix For: 1.0.0 Beta


It would be cool to have Forums deployed on JBoss Portal demo - http://portal.demo.jboss.com/ .

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 19:27:41 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Tue, 26 Sep 2006 19:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2696) Support other
 prepare[Statement|Call] methods
Message-ID: <1111910.1159313261712.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2696?page=comments#action_12344076 ] 
            
Weston Price commented on JBAS-2696:
------------------------------------

This looks done. Can we close this? 


> Support other prepare[Statement|Call] methods
> ---------------------------------------------
>
>                 Key: JBAS-2696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2696
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Adrian Brock
>
> Add support for other prepare[Statement|Call] methods.
> This will be more difficult since they are JDK1.4/JDBC3 which might not necessarily
> be supported by all drivers. e.g. result set Holdability.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 19:45:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Tue, 26 Sep 2006 19:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3705) Fixes included in
 JBAS-3689 for
 allowing the NamingService to work correctly in multi-homed environments
 need to be incorporated.
In-Reply-To: <11299157.1159310561613.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <292415.1159314341606.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3705?page=all ]

Scott M Stark closed JBAS-3705.
-------------------------------

    Resolution: Done

Updated http://wiki.jboss.org/wiki/Wiki.jsp?page=NamingSerivceMBean with new UseGlobalService attribute.


> Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 
> ----------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3705
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3705
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Fixes included in JBAS-3689 for allowing the NamingService to work correctly in multi-homed environments need to be incorporated. 

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 21:39:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 21:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3464) Add a wiki page
 explaining the implication of buddy replication for ClusteredSSO
In-Reply-To: <20154635.1154661372034.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4551412.1159321181665.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3464?page=all ]

Brian Stansberry closed JBAS-3464.
----------------------------------

    Resolution: Done

Wiki page is http://wiki.jboss.org/wiki/Wiki.jsp?page=BuddyReplicationAndClusteredSSO

> Add a wiki page explaining the implication of buddy replication for ClusteredSSO
> --------------------------------------------------------------------------------
>
>                 Key: JBAS-3464
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3464
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> Buddy replication is not particularly appropriate for SSO.  See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=88102 for details.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:30:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 26 Sep 2006 22:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (EJBTHREE-657) StatefulBean
 passivation is broken (ClassCastException in
 org.jboss.ejb3.stateful.NestedStatefulBeanContext)
In-Reply-To: <28564339.1153417331413.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15326210.1159324241867.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-657?page=all ]

Ben Wang resolved EJBTHREE-657.
-------------------------------

    Resolution: Done
      Assignee: Ben Wang

This should be fixed already in 4.0.5 and head. See EJBTHREE-612, 603, and 660. Unfortuntately, becuase of dependency on JBossCache release version (need 1.4), the latest EJB3 release doesn't contain these fixes. RC10 should have it though as long as 4.0.5 is out.

> StatefulBean passivation is broken (ClassCastException in org.jboss.ejb3.stateful.NestedStatefulBeanContext)
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: EJBTHREE-657
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-657
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC8 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Ben Wang
>            Priority: Critical
>
> StatefulBean passivation is broken, because there is a conflict between what gets serialized (attribute contains) and what gets unserialized (attribute beanMO).
> 11:41:37,109 ERROR [STDERR] Caused by: java.lang.ClassCastException: java.util.ArrayList
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.ejb3.stateful.NestedStatefulBeanContext.readExternal(Neste
> dStatefulBeanContext.java:60)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.persister.ExternalizePersister.readData(Externalize
> Persister.java:72)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.readObjectD
> escriptionFromStreaming(ObjectDescriptorFactory.java:411)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.objectFromD
> escription(ObjectDescriptorFactory.java:81)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectIn
> put.readObject(DataContainer.java:639)
> 11:41:37,109 ERROR [STDERR] 	at org.jboss.serial.persister.ObjectInputStreamProxy.readObjectOverride
> (ObjectInputStreamProxy.java:68)
> 11:41:37,109 ERROR [STDERR] 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:333)
> 11:41:37,109 ERROR [STDERR] 	at java.util.ArrayList.readObject(ArrayList.java:592)
> 11:41:37,109 ERROR [STDERR] 	... 74 more

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:33:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 26 Sep 2006 22:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-716) Add a flag to
 disable replication event notification
Message-ID: <31861900.1159324421774.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add a flag to disable replication event notification
----------------------------------------------------

                 Key: EJBTHREE-716
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-716
             Project: EJB 3.0
          Issue Type: Sub-task
          Components: Clustering
            Reporter: Ben Wang


This came up from an email thread:

(1) By default, passivation events get called during replication cycle
(2) There is a config setting to disable this
(3) We should introduce JBoss-specific replication-only and passivation-only events that actually let you directly write/read the bytestream
(4) I will work to get two sets of events into the next EJB spec, ie. introduce @PreReplicate / @PostReplicate or something like that

We should now tie the replication to passivation events (there is no concrete spec but everyone else is doing it). But we should also have a flag to disable it if needs to.


-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:33:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Tue, 26 Sep 2006 22:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-717) Introduce
 JBoss-specific
 replication-only events that actually let you directly write/read the
 bytestream
Message-ID: <6792703.1159324421914.JavaMail.jira@cloud.prod.atl2.jboss.com>

Introduce JBoss-specific replication-only events that actually let you directly write/read the bytestream
---------------------------------------------------------------------------------------------------------

                 Key: EJBTHREE-717
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-717
             Project: EJB 3.0
          Issue Type: Sub-task
          Components: Clustering
            Reporter: Ben Wang


Again, per email discussion. Idea is to let user has a fuller control of how replication process should be for sfsb.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 22:48:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Tue, 26 Sep 2006 22:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-789)
 DelegatingCacheLoader that can use a load balanced proxy
Message-ID: <6868317.1159325321520.JavaMail.jira@cloud.prod.atl2.jboss.com>

DelegatingCacheLoader that can use a load balanced proxy
--------------------------------------------------------

                 Key: JBCACHE-789
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-789
             Project: JBoss Cache
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Cache loaders
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 2.2.0


Using cache mode LOCAL and a DelegatingCacheLoader (aka a far-cache) has the potential to be a very performant cluster topology.  But, the far cache is a single point of failure.  Idea here is to develop an HA proxy to a cluster of far-caches; proxy pins to one far-cache, but can fail over to another if the primary target fails.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 23:03:41 2006
From: jira-events at jboss.com (Jon Stevens (JIRA))
Date: Tue, 26 Sep 2006 23:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3706) default version of
 jboss_init_redhat.sh is broken
Message-ID: <19255505.1159326221815.JavaMail.jira@cloud.prod.atl2.jboss.com>

default version of jboss_init_redhat.sh is broken
-------------------------------------------------

                 Key: JBAS-3706
                 URL: http://jira.jboss.com/jira/browse/JBAS-3706
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Jon Stevens


The jboss_init_redhat.sh script by default attempts to do a run.sh -c all which is useless given that server/all doesn't exist. It would be great to just have that -c all removed from the script. Additionally, it would be great if -c all and related server/all didn't exist that a nice error message would have been 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

        


From jira-events at jboss.com  Tue Sep 26 23:54:42 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Tue, 26 Sep 2006 23:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-2) Search Engine
Message-ID: <25230105.1159329282458.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-2?page=all ]

Sohil Shah reassigned JBFORUMS-2:
---------------------------------

    Assignee: Sohil Shah

> Search Engine
> -------------
>
>                 Key: JBFORUMS-2
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-2
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Sohil Shah
>            Priority: Blocker
>             Fix For: 1.1.0 Alpha
>
>
> JBoss Forums definitely needs a search engine.

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 23:57:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 23:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-366) Stateful
	interceptors
Message-ID: <16507766.1159329461686.JavaMail.jira@cloud.prod.atl2.jboss.com>

Stateful interceptors
---------------------

                 Key: JBSEAM-366
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-366
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Seam interceptors should be allowed to carry state, just like EJB3 interceptors

-- 
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

        


From jira-events at jboss.com  Tue Sep 26 23:57:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Tue, 26 Sep 2006 23:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-366) Stateful interceptors
In-Reply-To: <16507766.1159329461686.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10353821.1159329461816.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-366?page=all ]

Gavin King closed JBSEAM-366.
-----------------------------

    Resolution: Done

> Stateful interceptors
> ---------------------
>
>                 Key: JBSEAM-366
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-366
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Seam interceptors should be allowed to carry state, just like EJB3 interceptors

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:00:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 27 Sep 2006 00:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-367) "page parameters"
Message-ID: <24462794.1159329641562.JavaMail.jira@cloud.prod.atl2.jboss.com>

"page parameters"
-----------------

                 Key: JBSEAM-367
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-367
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


The following:

   <page view-id="/viewContact.xhtml">
      <param name="contactId" value="#{contact.id}"/>
   </page>

defines a "page parameter".

(1) when redirecting or linking to the view-id, the parameters are automagically added
(2) before rendering the view, the parameter values are applied back to the model

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:00:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-8) Search as you type
Message-ID: <28612347.1159329641739.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-8?page=all ]

Sohil Shah reassigned JBFORUMS-8:
---------------------------------

    Assignee: Sohil Shah

> Search as you type
> ------------------
>
>                 Key: JBFORUMS-8
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-8
>             Project: JBoss Forums
>          Issue Type: Feature Request
>            Reporter: Ryan Campbell
>         Assigned To: Sohil Shah
>             Fix For: 1.1.0 Alpha
>
>
> JBoss Portal should implement something like this for reducing duplicate posts:
> http://blogs.msdn.com/jledgard/archive/2005/07/28/444531.aspx
> So that as you type a post, your subject (and maybe body) are used as search terms against the forums or other content sources.  They show up in next to your text box, so even lazy users will see the search results relevant to their post.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:03:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Wed, 27 Sep 2006 00:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-367) "page parameters"
In-Reply-To: <24462794.1159329641562.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7342592.1159329821653.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-367?page=all ]

Gavin King closed JBSEAM-367.
-----------------------------

    Resolution: Done

Basically done, note that (1) only works when using <s:link> or directly returning the view-id as the outcome. note also that there are some minor lifecycle issues with (2).

> "page parameters"
> -----------------
>
>                 Key: JBSEAM-367
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-367
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> The following:
>    <page view-id="/viewContact.xhtml">
>       <param name="contactId" value="#{contact.id}"/>
>    </page>
> defines a "page parameter".
> (1) when redirecting or linking to the view-id, the parameters are automagically added
> (2) before rendering the view, the parameter values are applied back to the model

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:09:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:09:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-131) Refactor the
 PortalUtil functionality to an MBEAN approach
Message-ID: <24873096.1159330181583.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor the PortalUtil functionality to an MBEAN approach
----------------------------------------------------------

                 Key: JBFORUMS-131
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-131
             Project: JBoss Forums
          Issue Type: Task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 1.0.0 Beta


With this approach, different implementations for integrating the JSF system with JBoss Portal can be plugged in.

This will help better maintain the codebase to keep up with new portal releases

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:18:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-120) GUI for setting
 up security in JBForums
In-Reply-To: <23221067.1157042664516.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17909172.1159330721596.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-120?page=all ]

Sohil Shah reassigned JBFORUMS-120:
-----------------------------------

    Assignee: Sohil Shah

> GUI for setting up security in JBForums
> ---------------------------------------
>
>                 Key: JBFORUMS-120
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-120
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Forum Enhancements
>            Reporter: Ryszard Kozmik
>         Assigned To: Sohil Shah
>             Fix For: 1.1.0 Alpha
>
>
> We need a proper GUI for setting up security in forums. It should be much userfriendly than editing xml file.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:21:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-20) Finish bb code
	implementation
Message-ID: <8545438.1159330901805.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-20?page=all ]

Sohil Shah reassigned JBFORUMS-20:
----------------------------------

    Assignee: Ryszard Kozmik

> Finish bb code implementation
> -----------------------------
>
>                 Key: JBFORUMS-20
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-20
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Julien Viet
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.1.0 Alpha
>
>
> - [img] tag
> - [url=][/url]

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:21:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-109) BBCode support
 for standalone version
In-Reply-To: <12646323.1153947191321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8381677.1159330901932.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-109?page=all ]

Sohil Shah reassigned JBFORUMS-109:
-----------------------------------

    Assignee: Ryszard Kozmik

> BBCode support for standalone version
> -------------------------------------
>
>                 Key: JBFORUMS-109
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-109
>             Project: JBoss Forums
>          Issue Type: Task
>          Components: Forum Enhancements
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.1.0 Alpha
>
>
> BBCode parser is now working only in portal environment. We need make it work as a standalone too.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:24:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-125) BBCode URL Tag
	improvement
In-Reply-To: <3889348.1159038241186.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13763083.1159331081578.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-125?page=all ]

Sohil Shah reassigned JBFORUMS-125:
-----------------------------------

    Assignee: Ryszard Kozmik

> BBCode URL Tag improvement
> --------------------------
>
>                 Key: JBFORUMS-125
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-125
>             Project: JBoss Forums
>          Issue Type: Feature Request
>          Components: Forum Enhancements
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>             Fix For: 1.1.0 Alpha
>
>
> BBCode's URL tag could work similar to html "a href" style like : [url=http://www.example.com]My Example[/url]

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:24:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBFORUMS-17) poral 2.0 Users
 Guide Forums Portlet should be updated for new functionality
Message-ID: <17948309.1159331081755.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-17?page=all ]

Sohil Shah reassigned JBFORUMS-17:
----------------------------------

    Assignee: Ryszard Kozmik

>  poral 2.0 Users Guide Forums Portlet should be updated for new functionality
> -----------------------------------------------------------------------------
>
>                 Key: JBFORUMS-17
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-17
>             Project: JBoss Forums
>          Issue Type: Task
>         Environment: all
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>
> Portal 2.0 Users Guide - Forums Portlet chapter should be updated to describe new functionality like:
> -- polls
> -- user prefs
> -- moderators panel

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:27:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3312) LdapExtLoginModule is
 missing the first role group of a nested structure
Message-ID: <21667663.1159331261715.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3312?page=all ]

Scott M Stark closed JBAS-3312.
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                   JBossAS-5.0.0.Beta
                       (was: JBossAS-4.0.6.CR1)
       Resolution: Done
         Assignee: Scott M Stark  (was: Anil Saldhana)

The top level role is now queried for roleNameAttributeID in addition to following the roleAttributeID.

> LdapExtLoginModule is missing the first role group of a nested structure
> ------------------------------------------------------------------------
>
>                 Key: JBAS-3312
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3312
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> When traversing through a hiearchical role structure, the first matching context does not have its role name added to the resulting subject roles.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:27:41 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Wed, 27 Sep 2006 00:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3707) HA/Failover RAR
 Functionality should be implemented in non-HA RARS.
Message-ID: <1569192.1159331261829.JavaMail.jira@cloud.prod.atl2.jboss.com>

HA/Failover RAR Functionality should be implemented in non-HA RARS.
-------------------------------------------------------------------

                 Key: JBAS-3707
                 URL: http://jira.jboss.com/jira/browse/JBAS-3707
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: JBossAS-4.0.6.CR1
            Reporter: Weston Price
         Assigned To: Weston Price
            Priority: Optional


The HA/DB failover functionality for JDBC RARs currently exists in seperated deployments (ha/xa rars). This functionality should be put into the regular RARs as a deployment option and not as a standalone configuration which is unnecessary. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:30:41 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Wed, 27 Sep 2006 00:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3707) HA/Failover RAR
 Functionality should be implemented in non-HA RARS.
In-Reply-To: <1569192.1159331261829.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29247229.1159331441475.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3707?page=all ]

Weston Price updated JBAS-3707:
-------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974397#3974397

> HA/Failover RAR Functionality should be implemented in non-HA RARS.
> -------------------------------------------------------------------
>
>                 Key: JBAS-3707
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3707
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossAS-4.0.6.CR1
>            Reporter: Weston Price
>         Assigned To: Weston Price
>            Priority: Optional
>
> The HA/DB failover functionality for JDBC RARs currently exists in seperated deployments (ha/xa rars). This functionality should be put into the regular RARs as a deployment option and not as a standalone configuration which is unnecessary. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:33:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3301) LDAP/AD
 authentication "follow the memberOf chain"
Message-ID: <14932854.1159331621795.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3301?page=all ]

Scott M Stark updated JBAS-3301:
--------------------------------

                Issue Type: Patch  (was: Support Patch)
                  Workflow: jira  (was: JEMS Support Case Workflow v6)
    Support Case Reference:   (was: https://network.jboss.com/jbossnetwork/restricted/caseDetail.html?caseId=50030000002QK7W)
          Patch Visibility:   (was: [Public])

> LDAP/AD authentication "follow the memberOf chain"
> --------------------------------------------------
>
>                 Key: JBAS-3301
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3301
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Rafael Van Durm
>         Assigned To: Scott M Stark
>         Attachments: ADLoginModule.java
>
>
> For LDAP authentication, there are 2 possibilities for now: 
> - org.jboss.security.auth.spi.LdapLoginModule
> - org.jboss.security.auth.spi.LdapExtLoginModule
> Both do not support (as far as I understand) the "follow the memberOf chain" style of finding role definitions ...
> For example: authentication and authorisation for raf
> CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
> would result in group membership (=roles) 
>   inf_iedereen
>   web-gevonden
> I implemented this authorisation scheme quickly and attached the code over here ...
> Maybe also interesting for other people?

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:33:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3301) LDAP/AD
 authentication "follow the memberOf chain"
Message-ID: <16472395.1159331621982.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3301?page=all ]

Scott M Stark closed JBAS-3301.
-------------------------------

    Resolution: Duplicate Issue

This patch is obsoleted by the fix in JBAS-3312, LdapExtLoginModule is missing the first role group of a nested structure

> LDAP/AD authentication "follow the memberOf chain"
> --------------------------------------------------
>
>                 Key: JBAS-3301
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3301
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Security
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Rafael Van Durm
>         Assigned To: Scott M Stark
>         Attachments: ADLoginModule.java
>
>
> For LDAP authentication, there are 2 possibilities for now: 
> - org.jboss.security.auth.spi.LdapLoginModule
> - org.jboss.security.auth.spi.LdapExtLoginModule
> Both do not support (as far as I understand) the "follow the memberOf chain" style of finding role definitions ...
> For example: authentication and authorisation for raf
> CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=raf,OU=People,DC=uz,DC=kuleuven,DC=ac,DC=be
>   memberOf: CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   ...
> CN=web-gevonden,OU=WebRollen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
>   member: CN=inf_iedereen,OU=Informatiesystemen,OU=Groups,DC=uz,DC=kuleuven,DC=ac,DC=be
> would result in group membership (=roles) 
>   inf_iedereen
>   web-gevonden
> I implemented this authorisation scheme quickly and attached the code over here ...
> Maybe also interesting for other people?

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:36:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-10) LdapExtLoginModule
 is missing the first role group of a nested structure
Message-ID: <18824737.1159331801463.JavaMail.jira@cloud.prod.atl2.jboss.com>

LdapExtLoginModule is missing the first role group of a nested structure
------------------------------------------------------------------------

                 Key: SECURITY-10
                 URL: http://jira.jboss.com/jira/browse/SECURITY-10
             Project: JBoss Security
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Scott M Stark
         Assigned To: Scott M Stark


When traversing through a hiearchical role structure, the first matching context does not have its role name added to the resulting subject roles.  Duplicates JBAS-3312.


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:39:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Wed, 27 Sep 2006 00:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (SECURITY-10) LdapExtLoginModule
 is missing the first role group of a nested structure
In-Reply-To: <18824737.1159331801463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19453492.1159331981761.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SECURITY-10?page=all ]

Scott M Stark closed SECURITY-10.
---------------------------------

    Fix Version/s: 1.x
                   2.0
       Resolution: Done

> LdapExtLoginModule is missing the first role group of a nested structure
> ------------------------------------------------------------------------
>
>                 Key: SECURITY-10
>                 URL: http://jira.jboss.com/jira/browse/SECURITY-10
>             Project: JBoss Security
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Scott M Stark
>         Assigned To: Scott M Stark
>             Fix For: 1.x, 2.0
>
>
> When traversing through a hiearchical role structure, the first matching context does not have its role name added to the resulting subject roles.  Duplicates JBAS-3312.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:48:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-99) Jira Shows Real
 Name Rather than Alias After Create New Issue
In-Reply-To: <32262369.1152823031571.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4296061.1159332521897.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-99?page=all ]

Sohil Shah resolved JBFORUMS-99.
--------------------------------

    Resolution: Rejected

This is not a task on the Forums project

> Jira Shows Real Name Rather than Alias After Create New Issue
> -------------------------------------------------------------
>
>                 Key: JBFORUMS-99
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-99
>             Project: JBoss Forums
>          Issue Type: Bug
>         Environment: Browsing with Firefox 1.5
>            Reporter: Sascha Goldsmith
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>
> After posting a JIRA issue, I was shown a page summarizing my post.  On the left navigation area, it indicates 'author' with my real name, rather than my nic/alias.  Nearly everywhere else in the forums/site/etc., I am referred to by my alias/nic.  Having people's actual names posted seems a bit invasive from a privacy perspective.
> - Saish

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:54:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-30) Support
Message-ID: <17281039.1159332881697.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-30?page=all ]

Sohil Shah resolved JBFORUMS-30.
--------------------------------

    Resolution: Rejected

This is not a coding/documentation task to be associated with any particular software release as a feature, task, or a bug


Support is an ongoing service for the project

> Support
> -------
>
>                 Key: JBFORUMS-30
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-30
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>          Time Spent: 1 day, 2 hours, 20 minutes
>
> Answering e-mails and posts on forums.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 00:57:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 00:57:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBFORUMS-30) Support
Message-ID: <10464074.1159333061666.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBFORUMS-30?page=comments#action_12344091 ] 
            
Sohil Shah commented on JBFORUMS-30:
------------------------------------

irrespective of the release

> Support
> -------
>
>                 Key: JBFORUMS-30
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-30
>             Project: JBoss Forums
>          Issue Type: Task
>            Reporter: Ryszard Kozmik
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>          Time Spent: 1 day, 2 hours, 20 minutes
>
> Answering e-mails and posts on forums.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 01:15:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 01:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBFORUMS-17) poral 2.0 Users
 Guide Forums Portlet should be updated for new functionality
Message-ID: <23314541.1159334141733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBFORUMS-17?page=all ]

Sohil Shah resolved JBFORUMS-17.
--------------------------------

    Resolution: Duplicate Issue

See - http://jira.jboss.com/jira/browse/JBFORUMS-83

>  poral 2.0 Users Guide Forums Portlet should be updated for new functionality
> -----------------------------------------------------------------------------
>
>                 Key: JBFORUMS-17
>                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-17
>             Project: JBoss Forums
>          Issue Type: Task
>         Environment: all
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Ryszard Kozmik
>            Priority: Minor
>             Fix For: 1.1.0 Alpha
>
>
> Portal 2.0 Users Guide - Forums Portlet chapter should be updated to describe new functionality like:
> -- polls
> -- user prefs
> -- moderators panel

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 01:18:41 2006
From: jira-events at jboss.com (Sohil Shah (JIRA))
Date: Wed, 27 Sep 2006 01:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBFORUMS-132) Integrate a
 CommandMapper from
 JBoss Portal to make the Forum links more user-friendly
Message-ID: <28657975.1159334321598.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate a CommandMapper from JBoss Portal to make the Forum links more user-friendly
--------------------------------------------------------------------------------------

                 Key: JBFORUMS-132
                 URL: http://jira.jboss.com/jira/browse/JBFORUMS-132
             Project: JBoss Forums
          Issue Type: Task
    Affects Versions: 1.0.0 Alpha
            Reporter: Sohil Shah
         Assigned To: Sohil Shah
             Fix For: 1.1.0 Alpha




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 04:15:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 04:15:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3706) default version of
 jboss_init_redhat.sh is broken
In-Reply-To: <19255505.1159326221815.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10163429.1159344942029.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3706?page=all ]

Dimitris Andreadis closed JBAS-3706.
------------------------------------

    Fix Version/s: No Release
       Resolution: Duplicate Issue
         Assignee: Dimitris Andreadis

See JBAS-3217, the config to be used can be overriden and defaults to 'default' now.

> default version of jboss_init_redhat.sh is broken
> -------------------------------------------------
>
>                 Key: JBAS-3706
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3706
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Jon Stevens
>         Assigned To: Dimitris Andreadis
>             Fix For: No Release
>
>
> The jboss_init_redhat.sh script by default attempts to do a run.sh -c all which is useless given that server/all doesn't exist. It would be great to just have that -c all removed from the script. Additionally, it would be great if -c all and related server/all didn't exist that a nice error message would have been 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

        


From jira-events at jboss.com  Wed Sep 27 04:18:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 04:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2493) English Error in the
 jboss_init_redhat.sh
Message-ID: <4092121.1159345121710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2493?page=all ]

Dimitris Andreadis closed JBAS-2493.
------------------------------------

    Fix Version/s: No Release
       Resolution: Out of Date
         Assignee: Dimitris Andreadis

It's fixed in the latest (4.0.5) script.

> English Error in the jboss_init_redhat.sh
> -----------------------------------------
>
>                 Key: JBAS-2493
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2493
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: RHEL 4 update 2
>            Reporter: Kevin Sundberg
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: No Release
>
>
> in /jboss/bin/jboss_init_redhat.sh there is an english error
> #make java is on your path
> JAVAPTH=${JAVAPTH:-"/usr/java/jdk1.5.0_05/bin"}
> should read
> #make sure java is in your path
> JAVAPTH=${JAVAPTH:-"/usr/java/jdk1.5.0_05/bin"}

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:03:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Wed, 27 Sep 2006 05:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16809279.1159347821655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3702?page=comments#action_12344095 ] 
            
Galder Zamarreno commented on JBAS-3702:
----------------------------------------

Committed for 4.0.5.GA - EJBInvokerHA and JMXInvokerHA invokers were uncommented for all server port definitions

Asking about 5.0...

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:11:41 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 27 Sep 2006 05:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (EJBTHREE-718) Application
	client deployer
Message-ID: <17171510.1159348301740.JavaMail.jira@cloud.prod.atl2.jboss.com>

Application client deployer
---------------------------

                 Key: EJBTHREE-718
                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-718
             Project: EJB 3.0
          Issue Type: Task
    Affects Versions: EJB 3.0 RC10 - FD
            Reporter: Carlo de Wolf
         Assigned To: Carlo de Wolf


Build support for JavaEE 5 application clients (see EE.9 Application Clients)

- create a JBossXB parser for application_client_5.xsd
- create a client deployer
- create a client launcher

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:14:41 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 27 Sep 2006 05:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (EJBTHREE-718) Application
	client deployer
In-Reply-To: <17171510.1159348301740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7890562.1159348481530.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-718?page=all ]

Carlo de Wolf updated EJBTHREE-718:
-----------------------------------

    Priority: Critical  (was: Major)

> Application client deployer
> ---------------------------
>
>                 Key: EJBTHREE-718
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-718
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC10 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>
> Build support for JavaEE 5 application clients (see EE.9 Application Clients)
> - create a JBossXB parser for application_client_5.xsd
> - create a client deployer
> - create a client launcher

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:14:41 2006
From: jira-events at jboss.com (Carlo de Wolf (JIRA))
Date: Wed, 27 Sep 2006 05:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-718) Application
	client deployer
In-Reply-To: <17171510.1159348301740.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30691179.1159348481656.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-718?page=comments#action_12344096 ] 
            
Carlo de Wolf commented on EJBTHREE-718:
----------------------------------------

Parser is in revision 57228.

> Application client deployer
> ---------------------------
>
>                 Key: EJBTHREE-718
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-718
>             Project: EJB 3.0
>          Issue Type: Task
>    Affects Versions: EJB 3.0 RC10 - FD
>            Reporter: Carlo de Wolf
>         Assigned To: Carlo de Wolf
>            Priority: Critical
>
> Build support for JavaEE 5 application clients (see EE.9 Application Clients)
> - create a JBossXB parser for application_client_5.xsd
> - create a client deployer
> - create a client launcher

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:56:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 05:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-135) Null pointer
 exception in JCA XATerminator recover
Message-ID: <18998459.1159351001815.JavaMail.jira@cloud.prod.atl2.jboss.com>

Null pointer exception in JCA XATerminator recover
--------------------------------------------------

                 Key: JBTM-135
                 URL: http://jira.jboss.com/jira/browse/JBTM-135
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 05:56:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 05:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-135) Null pointer exception
 in JCA XATerminator recover
In-Reply-To: <18998459.1159351001815.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22182885.1159351002064.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-135?page=all ]

Mark Little closed JBTM-135.
----------------------------

    Resolution: Done

> Null pointer exception in JCA XATerminator recover
> --------------------------------------------------
>
>                 Key: JBTM-135
>                 URL: http://jira.jboss.com/jira/browse/JBTM-135
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation, JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.2.2
>
>          Time Spent: 15 minutes
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 06:12:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Wed, 27 Sep 2006 06:12:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17636089.1159351961533.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3702?page=all ]

Galder Zamarreno updated JBAS-3702:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta

Jboss 5.0 still uses the httpha-invokers, including EJBInvokerHA and JMXInvokerHA.
These also need to be uncommented in trunk's sample-bindings.xml.

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 06:15:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Wed, 27 Sep 2006 06:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3702) Uncomment HA
 invokers in sample-bindings.xml
In-Reply-To: <5748585.1159294661951.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24723355.1159352142002.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3702?page=all ]

Galder Zamarreno resolved JBAS-3702.
------------------------------------

    Resolution: Done

Uncommented for 4.0.x and trunk

> Uncomment HA invokers in sample-bindings.xml
> --------------------------------------------
>
>                 Key: JBAS-3702
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3702
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Galder Zamarreno
>         Assigned To: Galder Zamarreno
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>   Original Estimate: 1 hour
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Uncomment HA invokers (EJBInvokerHA and  JMXInvokerHA) from sample-bindings.xml.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 06:28:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 06:28:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-136) Check Windows services
Message-ID: <25459681.1159352921513.JavaMail.jira@cloud.prod.atl2.jboss.com>

Check Windows services
----------------------

                 Key: JBTM-136
                 URL: http://jira.jboss.com/jira/browse/JBTM-136
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTA Implementation, JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
            Priority: Minor




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 07:30:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Wed, 27 Sep 2006 07:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2696) Support other
 prepare[Statement|Call] methods
Message-ID: <1646075.1159356641491.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2696?page=comments#action_12344102 ] 
            
Adrian Brock commented on JBAS-2696:
------------------------------------

It's not done, compare the cached (mc.prepare...)

   public PreparedStatement prepareStatement(String sql, int resultSetType, int resultSetConcurrency)
         throws SQLException
   {
      checkTransaction();
      try
      {
         return new WrappedPreparedStatement(this, mc.prepareStatement(sql, resultSetType, resultSetConcurrency));
      }
      catch (Throwable t)
      {
         throw checkException(t);
      }
   }

with the non-cached (mc.getConnection().prepare...)

   public PreparedStatement prepareStatement(String sql, int autoGeneratedKeys) throws SQLException
   {
      checkTransaction();
      try
      {
         return new WrappedPreparedStatement(this, mc.getConnection().prepareStatement(sql, autoGeneratedKeys));
      }
      catch (Throwable t)
      {
         throw checkException(t);
      }
   }


> Support other prepare[Statement|Call] methods
> ---------------------------------------------
>
>                 Key: JBAS-2696
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2696
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>            Reporter: Adrian Brock
>
> Add support for other prepare[Statement|Call] methods.
> This will be more difficult since they are JDK1.4/JDBC3 which might not necessarily
> be supported by all drivers. e.g. result set Holdability.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:20:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 08:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBTM-29) Separate JTS/WS-T
 plugin for JBoss 5
Message-ID: <24685378.1159359641725.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-29?page=all ]

Mark Little updated JBTM-29:
----------------------------

     Affects: [Documentation (Ref Guide, User Guide, etc.), Interactive Demo/Tutorial, Compatibility/Configuration]  (was: [Interactive Demo/Tutorial, Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration])
    Assignee: Jonathan Halliday  (was: Mark Little)

> Separate JTS/WS-T plugin for JBoss 5
> ------------------------------------
>
>                 Key: JBTM-29
>                 URL: http://jira.jboss.com/jira/browse/JBTM-29
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Jonathan Halliday
>             Fix For: 4.6
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:23:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 08:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-116) Parameter checking
In-Reply-To: <21601302.1154698872133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7545430.1159359821824.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-116?page=all ]

Mark Little updated JBESB-116:
------------------------------

    Fix Version/s: 4.0

> Parameter checking
> ------------------
>
>                 Key: JBESB-116
>                 URL: http://jira.jboss.com/jira/browse/JBESB-116
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>
> Look at a convention like -paramname <param> for passing in parameters on the command line, rather than assuming element N in a list is param.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:38:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 08:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
Message-ID: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide unblock() callback and make changes in FLUSH to call unblock()
----------------------------------------------------------------------

                 Key: JGRP-330
                 URL: http://jira.jboss.com/jira/browse/JGRP-330
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
             Fix For: 2.4


#1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).

#2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:38:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 08:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
In-Reply-To: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5724023.1159360721883.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-330?page=comments#action_12344108 ] 
            
Bela Ban commented on JGRP-330:
-------------------------------

Callback unblock() has been added, class UnblockEvent was created

> Provide unblock() callback and make changes in FLUSH to call unblock()
> ----------------------------------------------------------------------
>
>                 Key: JGRP-330
>                 URL: http://jira.jboss.com/jira/browse/JGRP-330
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.4
>
>
> #1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).
> #2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:38:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Wed, 27 Sep 2006 08:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-150) There are too many
 magic numbers/strings in the code
Message-ID: <2024480.1159360722469.JavaMail.jira@cloud.prod.atl2.jboss.com>

There are too many magic numbers/strings in the code
----------------------------------------------------

                 Key: JBESB-150
                 URL: http://jira.jboss.com/jira/browse/JBESB-150
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


Particularly in the property space.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:41:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 08:41:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
In-Reply-To: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27610853.1159360901992.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-330?page=all ]

Bela Ban reassigned JGRP-330:
-----------------------------

    Assignee: Vladimir Blagojevic  (was: Bela Ban)

Please make the necessary changes as discussed to call unblock() (or add an UnblockEvent to the receiver queue if pull-mode is used)

> Provide unblock() callback and make changes in FLUSH to call unblock()
> ----------------------------------------------------------------------
>
>                 Key: JGRP-330
>                 URL: http://jira.jboss.com/jira/browse/JGRP-330
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.4
>
>
> #1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).
> #2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 08:47:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 08:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3598) Get the 4.0.5.GA
 testsuite-1.4 (JRockit) passing
In-Reply-To: <31303322.1157127343880.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15859838.1159361261873.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3598?page=comments#action_12344110 ] 
            
Dimitris Andreadis commented on JBAS-3598:
------------------------------------------

The failing UIL2JBossMQUnitTestCase in the last run, passes for me

one-test:
    [mkdir] Created dir: X:\cvs\jboss-public\jboss-4.0\testsuite\output\log
    [junit] Running org.jboss.test.jbossmq.test.UIL2JBossMQUnitTestCase
    [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 104.871 sec

BUILD SUCCESSFUL
Total time: 1 minute 51 seconds

> 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
>         Assigned To: 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

        


From jira-events at jboss.com  Wed Sep 27 08:50:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 08:50:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <20988747.1159361442100.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344111 ] 
            
Dimitris Andreadis commented on JBAS-2299:
------------------------------------------

Clebert, I suppose you are not working on this?

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 09:03:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 09:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3582) Get the ejb3-4.0
 testsuite passing
In-Reply-To: <28677268.1156859718767.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31736964.1159362221693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3582?page=all ]

Dimitris Andreadis updated JBAS-3582:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

I'm probably talking to myself.

> Get the ejb3-4.0 testsuite passing
> ----------------------------------
>
>                 Key: JBAS-3582
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3582
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Bill Burke
>             Fix For: JBossAS-4.0.6.CR1
>
>
> There are currenlty 28 failures

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 10:38:42 2006
From: jira-events at jboss.com (Weston Price (JIRA))
Date: Wed, 27 Sep 2006 10:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3693) Other XAResource
	errors
In-Reply-To: <21206614.1159185421122.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3315064.1159367922656.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3693?page=all ]

Weston Price updated JBAS-3693:
-------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-4.0.5.CR1)

Fix fix version.

> Other XAResource errors
> -----------------------
>
>                 Key: JBAS-3693
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3693
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: JCA service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Adrian Brock
>         Assigned To: Weston Price
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> Further to JBAS-3336 (resource manager error during enlist should close the connection). 
> There are other xa resource failures that need to be catered for.
> e.g. a failure to delist probably means a problem with the connection.
> Also, this could be dealt with at the rar level? e.g. the jdbc XAManagedConnection
>    public void end(Xid xid, int flags) throws XAException
>    {
> +      try
> +      {
>          xaResource.end(xid, flags);
> +      }
> +      catch (XAException e)
> +      {
> +          broadcastConnectionError(e);
> +          throw e;
> +      }
> ...

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:02:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 27 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3709) Access Control on
 JMX Operations in the JMX Console[Patch]
Message-ID: <7386034.1159372961525.JavaMail.jira@cloud.prod.atl2.jboss.com>

Access Control on JMX Operations in the JMX Console[Patch]
----------------------------------------------------------

                 Key: JBAS-3709
                 URL: http://jira.jboss.com/jira/browse/JBAS-3709
             Project: JBoss Application Server
          Issue Type: Support Patch
      Security Level: Public (Everyone can see)
          Components: Security
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana


Create a patch for JBoss 3.2.3

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:14:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 12:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25642459.1159373681654.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3699?page=comments#action_12344117 ] 
            
Dimitris Andreadis commented on JBAS-3699:
------------------------------------------

According to WS team, this is going to be solved with jbossws-1.0.4 (Oct/31st), so no service pack for now.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:45:41 2006
From: jira-events at jboss.com (Chris Laprun (JIRA))
Date: Wed, 27 Sep 2006 12:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBPORTAL-1016) Allow creation
 and deployment of WSRP portlets from descriptors
In-Reply-To: <12244662.1157064078725.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17744613.1159375541716.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1016?page=all ]

Chris Laprun reassigned JBPORTAL-1016:
--------------------------------------

    Assignee: Julien Viet  (was: Chris Laprun)

> Allow creation and deployment of WSRP portlets from descriptors
> ---------------------------------------------------------------
>
>                 Key: JBPORTAL-1016
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1016
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal WSRP
>    Affects Versions: 2.4 Final
>            Reporter: Chris Laprun
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final
>
>
> Right now, the only way to deploy WSRP portlets is via the management portlet. We should be able to do this via the descriptors. Proposed solution is to evolve the -wsrp.xml file to accomodate portlet definition.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 12:51:41 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 27 Sep 2006 12:51:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1059) Fix Theme module
	tests
Message-ID: <15268729.1159375901621.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix Theme module tests
----------------------

                 Key: JBPORTAL-1059
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1059
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Theme
    Affects Versions: 2.6.Alpha1
            Reporter: Roy Russo
         Assigned To: Roy Russo
             Fix For: 2.6.Alpha1


Changes in the testsuite runner, have made the theme api tests not deploy/run.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:06:41 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Wed, 27 Sep 2006 13:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3704) Add a notion of
 available interfaces to org.jboss.test.util.server.*
In-Reply-To: <18012080.1159299761464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1720300.1159376801612.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3704?page=all ]

Ryan Campbell reassigned JBAS-3704:
-----------------------------------

    Assignee: Rajesh Rajasekaran

> Add a notion of available interfaces to org.jboss.test.util.server.*
> --------------------------------------------------------------------
>
>                 Key: JBAS-3704
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3704
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Scott M Stark
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.6.CR1
>
>
> An issue with automating testing involving binding to specific addresses is that there is no predefined set of properties a testsuite descriptor can reference. The qa env has MYTESTIP_1 type of env vars set, and java 1.4.2+ has java.net.NetworkInterface, that could be used as the basis for defining jboss.server.iface.0..N system properties that configurations could rely on for setting one or more bind interfaces.
> We need to add this functionality to the server startup tasks.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:24:41 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 13:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBREM-606) patch to 1.4.4.GA to
 include fix for socket server thread leak
Message-ID: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>

patch to 1.4.4.GA to include fix for socket server thread leak
--------------------------------------------------------------

                 Key: JBREM-606
                 URL: http://jira.jboss.com/jira/browse/JBREM-606
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: transport
    Affects Versions: 1.4.4.GA
            Reporter: Tom  Elrod
         Assigned To: Tom  Elrod
             Fix For: 1.4.5.GA


Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:27:41 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 13:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-606) patch to 1.4.4.GA
 to include fix for socket server thread leak
In-Reply-To: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9414905.1159378061844.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-606?page=comments#action_12344124 ] 
            
Tom  Elrod commented on JBREM-606:
----------------------------------

Have also back ported code change for JBREM-529 so that native socket will be re-used instead of sitting in TIME_WAIT state.

> patch to 1.4.4.GA to include fix for socket server thread leak
> --------------------------------------------------------------
>
>                 Key: JBREM-606
>                 URL: http://jira.jboss.com/jira/browse/JBREM-606
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.4.GA
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 1.4.5.GA
>
>
> Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:30:42 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 13:30:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBREM-606) patch to 1.4.4.GA
 to include fix for socket server thread leak
In-Reply-To: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16519423.1159378242855.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-606?page=all ]

Tom  Elrod resolved JBREM-606.
------------------------------

    Resolution: Done

> patch to 1.4.4.GA to include fix for socket server thread leak
> --------------------------------------------------------------
>
>                 Key: JBREM-606
>                 URL: http://jira.jboss.com/jira/browse/JBREM-606
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.4.GA
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 1.4.5.GA
>
>
> Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:54:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <14951009.1159379681866.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344128 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

Common-BeanUtils is broken:

org.jboss.web.tomcat.tc5.WebAppClassLoader at 6455597
!--- class org.apache.struts.action.ActionServlet
!--- !--- [Ljava.lang.Class;@15889588
!--- !--- !--- java.lang.reflect.Method at 2653351
!--- !--- !--- !--- [Ljava.lang.reflect.Method;@14422877
!--- !--- !--- !--- !--- java.util.Hashtable$Entry at 23818829
!--- !--- !--- !--- !--- !--- [Ljava.util.Hashtable$Entry;@18693832
!--- !--- !--- !--- !--- !--- !--- java.util.Hashtable at 17102985
!---!---!---!---!---!---!---!--- StaticFieldReference private static java.util.Hashtable org.apache.commons.beanutils.MappedPropertyDescriptor.declaredMethodCache  Detail


There is a list of declaredMethods (Reflection) being referenced inside of MappedPropertyDescriptor.

BeanUtils is now being bundled with JBoss/JSF at this point.


If you want to avoid this bug for this specific application, having BeanUtils deployed within the application + classLoader isolations will make BeanUtils to keep circular references inside the classLoader what would avoid the contention.


We should look for a way to contribute a fix for apache.

Besides this reflection cache, it looks also they have a circular reference on their WeakHashMap, having the classLoader on the value. (but I'm not sure about that one).
But I know for sure BeanUtils is broken.

Dimitris, since this is a Beanutils bug, what should we do here? Close, postpone? It's your call now.

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:57:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:57:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <9946481.1159379862428.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Assignee: Dimitris Andreadis  (was: Clebert Suconic)

Dimitris: I'm assigning this to you, just to you take a look on what to do next. If you want me to take a look on this again during 4.0.6, I can look at it. For now I'm assigning this to you just for you take a decision.

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:57:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:57:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <24753981.1159379862927.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic reassigned JBAS-2299:
-------------------------------------

    Assignee: Clebert Suconic  (was: Dimitris Andreadis)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Clebert Suconic
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 13:57:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 13:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <23974749.1159379863774.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Clebert Suconic updated JBAS-2299:
----------------------------------

    Assignee: Dimitris Andreadis  (was: Clebert Suconic)

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:00:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <7798227.1159380041920.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344130 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

I just realized Adrian's comment on BeanUtils. So I didn't discover anything new here.

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: Data.txt, SampleApp.ear
>
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:06:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3710) WebServices leaking
	redeployment
Message-ID: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>

WebServices leaking redeployment
--------------------------------

                 Key: JBAS-3710
                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Web Services
            Reporter: Clebert Suconic
         Assigned To: Thomas Diesler
            Priority: Blocker




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:06:41 2006
From: jira-events at jboss.com (Cutberto Ocampo (JIRA))
Date: Wed, 27 Sep 2006 14:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-732) remove process
 start link for processes without start task
In-Reply-To: <7236390.1155567977653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5585042.1159380401927.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-732?page=comments#action_12344132 ] 
            
Cutberto Ocampo commented on JBPM-732:
--------------------------------------

It would be nice to have a feature that allows process developers/designers to define an "external" interactive application to launch in case a task is executed (a la Carnot). For example, I would like to deploy a JSP in the same app server where jBPM is living, so I could execute the JSP so this (via a controller) has access to task/process instance variables.

This way, I could have the freedom to develop my own GUI's without them worrying about the complexities of business workflow (since this would be in the process, not in the JSP); the JSP would handle the complexity of validations, access to the model, etc. However, there may be a problem whenever you try to release a new version of the process, or a new version of the JSP(s), since the variables shared by both of them need to be synchronized (while designing the process and developing the JSP).

Please correct me if I'm expressing something wrong.

> remove process start link for processes without start task
> ----------------------------------------------------------
>
>                 Key: JBPM-732
>                 URL: http://jira.jboss.com/jira/browse/JBPM-732
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> a check should be added to the start new process execution list on the home page that verifies if the process has a forms.xml.  if not, the start process link should not be 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

        


From jira-events at jboss.com  Wed Sep 27 14:06:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3710) WebServices leaking
	redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10666269.1159380402097.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3710?page=all ]

Clebert Suconic updated JBAS-3710:
----------------------------------

    Description: JBWS-1228 has the description for this bug

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:09:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3710) WebServices leaking
 redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23393134.1159380583632.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3710?page=comments#action_12344133 ] 
            
Clebert Suconic commented on JBAS-3710:
---------------------------------------

This bug needs to be addressed somehow. 

We have talked internally about removing the testsuite for WS and just ignore this bug on the release.

That decision has to be taken.

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:09:43 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Wed, 27 Sep 2006 14:09:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3710) WebServices leaking
	redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13047071.1159380583866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3710?page=all ]

Clebert Suconic updated JBAS-3710:
----------------------------------

        Fix Version/s: JBossAS-4.0.5.GA
    Affects Version/s: JBossAS-4.0.5.CR1

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:23:42 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 14:23:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBREM-606) patch to 1.4.4.GA
 to include fix for socket server thread leak
In-Reply-To: <7186488.1159377881512.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30283160.1159381422339.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBREM-606?page=comments#action_12344135 ] 
            
Tom  Elrod commented on JBREM-606:
----------------------------------

Also back ported fix for JBREM-372 (memory leak within leasing).

> patch to 1.4.4.GA to include fix for socket server thread leak
> --------------------------------------------------------------
>
>                 Key: JBREM-606
>                 URL: http://jira.jboss.com/jira/browse/JBREM-606
>             Project: JBoss Remoting
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: transport
>    Affects Versions: 1.4.4.GA
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>             Fix For: 1.4.5.GA
>
>
> Need to back port fix for JBREM-409.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:34:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Wed, 27 Sep 2006 14:34:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3710) WebServices leaking
 redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21946955.1159382081567.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3710?page=comments#action_12344137 ] 
            
Dimitris Andreadis commented on JBAS-3710:
------------------------------------------

Disabling the ws tests in the testsuite is made to let us fix the rest of the testsuite, not to ignore the bug!

> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 14:50:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Wed, 27 Sep 2006 14:50:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-331) Backport
 configuration for TCP's nagling from 2.4
Message-ID: <12248647.1159383041684.JavaMail.jira@cloud.prod.atl2.jboss.com>

Backport configuration for TCP's nagling from 2.4
-------------------------------------------------

                 Key: JGRP-331
                 URL: http://jira.jboss.com/jira/browse/JGRP-331
             Project: JGroups
          Issue Type: Task
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.2.7 SP1




-- 
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

        


From jira-events at jboss.com  Wed Sep 27 15:05:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 15:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3711) Update to JGroups
	2.2.7.SP1
Message-ID: <16504659.1159383941683.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update to JGroups 2.2.7.SP1
---------------------------

                 Key: JBAS-3711
                 URL: http://jira.jboss.com/jira/browse/JBAS-3711
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-4.0.5.GA


JGroups will release a 2.2.7.SP1 in the next day or so.  This will provide the ability to set TCP_NO_DELAY on TCP sockets. Integrate this so 4.0.5.GA can have reduced RPC call latency when using a TCP config.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 16:47:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Wed, 27 Sep 2006 16:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (SECURITY-11) Principal To Role
 mapping provider
Message-ID: <29447996.1159390061680.JavaMail.jira@cloud.prod.atl2.jboss.com>

Principal To Role mapping provider
----------------------------------

                 Key: SECURITY-11
                 URL: http://jira.jboss.com/jira/browse/SECURITY-11
             Project: JBoss Security
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: JBossSX
            Reporter: Anil Saldhana
         Assigned To: Anil Saldhana
             Fix For: 2.0


We need a mechanism that will allow a user to configure a mapping of principal to roles that need to be added to the security context.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 16:56:43 2006
From: jira-events at jboss.com (Tom  Elrod (JIRA))
Date: Wed, 27 Sep 2006 16:56:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBREM-124) implement APR
	transport
Message-ID: <14079103.1159390603510.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBREM-124?page=all ]

Tom  Elrod updated JBREM-124:
-----------------------------

    Priority: Critical  (was: Optional)

> implement APR transport
> -----------------------
>
>                 Key: JBREM-124
>                 URL: http://jira.jboss.com/jira/browse/JBREM-124
>             Project: JBoss Remoting
>          Issue Type: Task
>          Components: transport
>    Affects Versions: 1.2.0 final
>            Reporter: Tom  Elrod
>         Assigned To: Tom  Elrod
>            Priority: Critical
>             Fix For: 2.2.0.Beta1 (Bluto)
>
>
> Need to add support of Apache APR based transport.  The APR code (from tomcat-connector project) uses native code to manage threads and sockets.  The end result is a much better performance using a NIO type approach where only have threads in use for processing data off the socket.  When socket is idle, the threads are released and the native code will callback to activate a thread to process the data.  
> This effort has already been started in JBossRemoting on a branch called apr_transport.  Will probably not be fully implemented till after 1.2.0 release.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:12:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:12:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <17315545.1159395162513.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-5.0.0.Beta)

Changing to 4.0.5.GA as I expect to resolve this in next 24 hours.

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:12:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:12:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2272) Clustering unit test
 failures - TCP stack
Message-ID: <1216883.1159395162767.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2272?page=all ]

Brian Stansberry updated JBAS-2272:
-----------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
                       (was: JBossAS-5.0.0.Beta)

Changing to 4.0.5.GA as I expect to resolve this in next 24 hours.

> Clustering unit test failures - TCP stack
> -----------------------------------------
>
>                 Key: JBAS-2272
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2272
>             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-4.0.5.GA
>
>
> Resolve why we get numerous test case failures when using the tcp stack, even if as much as 2 seconds are allowed for state propagation across the cluster.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:12:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:12:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2560) Replace the
 MockHAPartition unit test with one that uses a JGroups GossipRouter
Message-ID: <19102369.1159395162905.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2560?page=all ]

Brian Stansberry updated JBAS-2560:
-----------------------------------

    Fix Version/s: JBossAS-5.0.1.CR1
                       (was: JBossAS-5.0.0.Beta)

> Replace the MockHAPartition unit test with one that uses a JGroups GossipRouter
> -------------------------------------------------------------------------------
>
>                 Key: JBAS-2560
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2560
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.1.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:18:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:18:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2837) When using Cache
 Invalidation
 Framework don't remove from cache the specific bean that was changed
Message-ID: <18324054.1159395521991.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2837?page=all ]

Brian Stansberry updated JBAS-2837:
-----------------------------------

    Fix Version/s: No Release

Changing fix version from "None" to "No Release" as that's the version that means "not sure when, but not soon."

> When using Cache Invalidation Framework don't remove from cache the specific bean that was changed
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2837
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2837
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, EJB2
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: No Release
>
>
> Currently if an entity bean is modified, the CIF not only invalidates the cache for any local beans in the same invalidation group, but also removes the bean that was changed from the cache.  This reduces the usefulness of commit option A.
> See forum thread for details.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:21:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2790) JBento setup
	improvements
Message-ID: <22992221.1159395701552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2790?page=all ]

Brian Stansberry closed JBAS-2790.
----------------------------------

    Resolution: Rejected

The described improvements are done, but I'm closing as "Rejected" as this shouldn't be in the AS release notes -- doing it only indirectly impacts the AS.

> JBento setup improvements
> -------------------------
>
>                 Key: JBAS-2790
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2790
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> Currently tweaking aspects of the app server config for our JBento environment is a pain, as all tweaks have to be copied to the various /server/xyx folders.
> Create a config folder in the jbento dir, and store the various configurable files there.  Then in the server/xyz folders, have symlinks pointing to these files.
> Include:
> tc5-cluster-service.xml
> jgroups.jar (various releases, with a symlink pointing to the one in use)
> jboss-cache.jar (as above)
> jboss-web.xml
> log4j.xml

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:24:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:24:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2292)
 DistributedReplicantManager does
 not honor jmx service dependencies when notifiyng a node removal
Message-ID: <25269171.1159395882111.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2292?page=all ]

Brian Stansberry updated JBAS-2292:
-----------------------------------

    Fix Version/s: No Release

Fix version "No Release" means "not sure when, but not soon."

> DistributedReplicantManager does not honor jmx service dependencies when notifiyng a node removal
> -------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-2292
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2292
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.2 Final
>         Environment: Jboss 4.0.2, 
> WinXP
> JDK 1.5
>            Reporter: janssk1
>         Assigned To: Brian Stansberry
>             Fix For: No Release
>
>
> We are using some HASingletonServices. These services use the HAJNDI tree to lookup other services. 
> Both the HASingletonservices and the HAJNDI service are notified if a node (eg the master) is removed from the cluster. However, the order seems to be random. If the master goes down, the HASingletonservce seems to be notified first. It tries to start the singleton on another host. While starting, it uses the HAJNDI, but this one still tries to connect to the old server, leading to NamingExceptions. 
> Since i added a jmx depencency from the singleton service to HAJNDI, i would expect that the HAJNDI gets notified first. That would fix my problem. 
> I looked in the code of the DistributedReplicantManagerImpl and it seems that this one does not keep track of the order in which keys are registered. I quickly changed all HashMap and HashSet instantiations of this class to LinkedHashMap and LinkedHashSet instantiations, and now my problem is fixed. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3648) Need a clustered ejb
 compatibility test
In-Reply-To: <17070980.1158097117897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6106287.1159396061878.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3648?page=all ]

Brian Stansberry updated JBAS-3648:
-----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1

> Need a clustered ejb compatibility test
> ---------------------------------------
>
>                 Key: JBAS-3648
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3648
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.8.SP1
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-3.2.8.SP2
>
>
> We need a test of a 3.2.x client talking to a 4.0.x clustered ejb to validate interop.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3502) Use
 ProcessExpiresFrequency to speed tests involving session timeout
In-Reply-To: <300803.1155154392870.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2338397.1159396062004.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3502?page=all ]

Brian Stansberry updated JBAS-3502:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.GA

> Use ProcessExpiresFrequency to speed tests involving session timeout
> --------------------------------------------------------------------
>
>                 Key: JBAS-3502
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3502
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering, Test Suite
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.GA
>
>
> Tomcat Manager impls expose a property ProcessExpiresFrequency, which controls how often the manager responds to the TC background process thread.  By default it is set to 6, which means the manager does a session cleanup every 6 cycles.  By default the thread runs every 10 secs, so that means session are expired once per minute.
> Need to add ProcessExpiresFrequency=1 to a context.xml deployed with session test webapps so we can reduce the time it takes for tests involving session expiration to complete.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3648) Need a clustered ejb
 compatibility test
In-Reply-To: <17070980.1158097117897.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21379049.1159396062171.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3648?page=all ]

Brian Stansberry updated JBAS-3648:
-----------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2

> Need a clustered ejb compatibility test
> ---------------------------------------
>
>                 Key: JBAS-3648
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3648
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-3.2.8.SP1
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.6.CR1, JBossAS-3.2.8.SP2
>
>
> We need a test of a 3.2.x client talking to a 4.0.x clustered ejb to validate interop.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3647) Backport
 SingleRetryInterceptor to 3.2
In-Reply-To: <4654533.1158096992808.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33466312.1159396062361.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3647?page=all ]

Brian Stansberry updated JBAS-3647:
-----------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2

> Backport SingleRetryInterceptor to 3.2
> --------------------------------------
>
>                 Key: JBAS-3647
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3647
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, EJB2
>    Affects Versions: JBossAS-3.2.8.SP1
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-3.2.8.SP2
>
>
> A 3.2.8.SP1 client attempting to connect to a 4.0.4 clustered bean fails with the following error due to the SingleRetryInterceptor not being available in 3.2.8.SP1:
> 2006-09-12 16:44:30,178 [Thread-0::] - javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException:
> org.jboss.proxy.ejb.SingleRetryInterceptor (no security manager: RMI class loader disabled)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:318)
> at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:132)
> at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:143)
> at java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:918)
> We should backport this.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:27:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3556) Add non-integration
 based testing to cluster module
In-Reply-To: <8862893.1156352389582.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7152954.1159396062506.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3556?page=all ]

Brian Stansberry updated JBAS-3556:
-----------------------------------

    Fix Version/s: JBossAS-5.0.1.CR1

> Add non-integration based testing to cluster module
> ---------------------------------------------------
>
>                 Key: JBAS-3556
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3556
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, Test Suite
>            Reporter: Brian Stansberry
>             Fix For: JBossAS-5.0.1.CR1
>
>
> All the unit tests for the AS cluster module are run via the testsuite tests-clustering target, which starts two AS instances.  This is painful and time consuming and discourages writing of simple unit tests that exercise a particular class, with no need for a larger integration.
> Need to set up a src/tests tree in the cluster module, add simple unit tests to it, and integrate that into the overall testsuite run.  The security module has this kind of setup; look to that to see how the overall testsuite integration is done.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:30:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3257) HANamingService:
 Enable definition of RmiBindAddress analogous to RmiBindPort
Message-ID: <17052358.1159396241655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3257?page=comments#action_12344163 ] 
            
Brian Stansberry commented on JBAS-3257:
----------------------------------------

Jerry, can you assign a Fix Version to this? If the answer is "no time in the next 9 months", please set Fix Version to "No Release".

> HANamingService: Enable definition of RmiBindAddress analogous to RmiBindPort
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-3257
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3257
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: Solaris, use gnu patch to apply patchfile:
> /opt/gnu/bin/patch < patch.txt
>            Reporter: Jerry Gauthier
>         Assigned To: Jerry Gauthier
>         Attachments: patch.txt
>
>
> Reported by Thomas Wenckebach - see JBCLUSTER-94
> Consider the following setting:
> In multi home cluster environments you might want to bind the HANamingService Port to a High Available (virtual) IP address, whereas the NamingService Port would be a local ("real") IP address in this case (different LANs). Note that it is strictly mandatory in this setting to also bind the RmiPort of HANamingService to a local IP address, since it is referenced internally via the system property java.rmi.server.hostname - a conceptual flaw, since it is also used for referencing the NamingService. Consequently, it is a must to bind both NamingService and HANamingService RmiPorts to the same interface. From this fact follows the necessity to bind HANamingService RmiPort to an interface different from the one used by HANamingService Port!
> Simply do the following:
> $> cd jboss-4.0.3SP1-src/cluster/src/main/org/jboss/ha/jndi
> $> /opt/gnu/bin/patch < patch.txt
> ( please find patch.txt attached! )

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:33:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3138) HAJNDI lookup fails
 intermittently from twiddle
Message-ID: <26343475.1159396421552.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3138?page=all ]

Brian Stansberry updated JBAS-3138:
-----------------------------------

    Fix Version/s: No Release

Fix version "No Release" means "not sure when, but not soon."

> HAJNDI lookup fails intermittently from twiddle
> -----------------------------------------------
>
>                 Key: JBAS-3138
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3138
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Clustering, JMX, Naming
>    Affects Versions: JBossAS-5.0.0.Beta, JBossAS-4.0.4.CR2
>         Environment: This bug is present in JBoss 3.2.6 and 4.0.3. To produce setup a two node cluster, such as in the lab-clustering. This bug is reproducable on Windows XP, Linux WS3, & Solaris 10.
>            Reporter: Brian Stansberry
>            Priority: Minor
>             Fix For: No Release
>
>
> Brian Egge reported in JBCLUSTER-83:
> Running twiddle against the HAJNDI port will sometimes fail, and sometimes work. It does not matter if you query the server which has the component, or the failover server. Both produce the same result. Using the standard JDNI port always works, if you query the correct server. Using the HAJNDI fails ~50% of the time:
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1200 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> 12:26:40,320 ERROR [Twiddle] Exec failed
> javax.management.InstanceNotFoundException: jboss.mq.destination:name=A,service=Queue is not registered.
>         at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:508)
>         at org.jboss.mx.server.MBeanServerImpl.getAttributes(MBeanServerImpl.java:547)
>         at sun.reflect.GeneratedMethodAccessor83.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:251)
>         at sun.reflect.GeneratedMethodAccessor81.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.invocation.jrmp.server.JRMPProxyFactory.invoke(JRMPProxyFactory.java:164)
>         at sun.reflect.GeneratedMethodAccessor80.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
>         at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
>         at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
>         at sun.reflect.GeneratedMethodAccessor79.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
>         at sun.rmi.transport.Transport$1.run(Transport.java:153)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
>         at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
>         at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
>         at java.lang.Thread.run(Thread.java:595)
> The JNDI port always works:
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1199 get jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> C:\JBossAdvancedJ2EE\labs\jboss-4.x\bin>twiddle --server=jnp://localhost:1199 get "jboss.mq.destination:name=A,service=Queue" ReceiversCount QueueName
> ReceiversCount=0
> QueueName=A
> * In these examples, clust2 is running using the bind config port-01, which adds 100 to the ports. The bug is the same when on a single machine or multiple. The above examples are the same when using 1099/1100. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:33:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2440) Review use of
 HashMap vs. Map as
 a type declaration in DistributedReplicantManagerImpl
Message-ID: <17987664.1159396421794.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2440?page=all ]

Brian Stansberry updated JBAS-2440:
-----------------------------------

    Fix Version/s: JBossAS-5.0.0.CR1

> Review use of HashMap vs. Map as a type declaration in DistributedReplicantManagerImpl
> --------------------------------------------------------------------------------------
>
>                 Key: JBAS-2440
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2440
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Jerry Gauthier
>             Fix For: JBossAS-5.0.0.CR1
>
>
> There are a lot of places in DistributedReplicantManagerImpl where variables are declared as HashMap instead of Map.  Since a number of internal members have been changed to ConcurrentReaderHashMap, this is dangerous (see JBAS-2439).  Need to review and where possible use Map instead of HashMap.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 18:36:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 18:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2470) Test multiple
 partitions and subsequent merges using Gossip Router
Message-ID: <33004143.1159396601624.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2470?page=all ]

Brian Stansberry updated JBAS-2470:
-----------------------------------

    Fix Version/s: JBossAS-5.0.1.CR1

> Test multiple partitions and subsequent merges using Gossip Router
> ------------------------------------------------------------------
>
>                 Key: JBAS-2470
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2470
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-5.0.1.CR1
>
>
> Create tests of the merge handling of HAPartition and related classes by using a GossipRouter in the JGroups config. A split in the partition can be simulated by killing the GR, merge
> can be triggered by restarting it.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 19:48:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Wed, 27 Sep 2006 19:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
In-Reply-To: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1354393.1159400921689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1045?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1045.
-------------------------------------------

    Resolution: Done

> port OpenDS integration from JBoss AS testsuite to portal testsuite
> -------------------------------------------------------------------
>
>                 Key: JBPORTAL-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Test
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 16 minutes
>
> Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 20:54:41 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Wed, 27 Sep 2006 20:54:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1059) Fix Theme
	module tests
In-Reply-To: <15268729.1159375901621.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25340788.1159404881652.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1059?page=all ]

Roy Russo resolved JBPORTAL-1059.
---------------------------------

    Resolution: Done

> Fix Theme module tests
> ----------------------
>
>                 Key: JBPORTAL-1059
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1059
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.6.Alpha1
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> Changes in the testsuite runner, have made the theme api tests not deploy/run.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:42:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3712) Use TCP_NO_DELAY on
 sockets if HAPartition uses TCP
Message-ID: <8193195.1159407761620.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use TCP_NO_DELAY on sockets if HAPartition uses TCP
---------------------------------------------------

                 Key: JBAS-3712
                 URL: http://jira.jboss.com/jira/browse/JBAS-3712
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-4.0.5.GA


HAPartition makes synchronous RPC calls; to improve latency we should disabling nagling by setting the new JGroups TCP.tcp_nodelay flag to true.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:48:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3712) Use TCP_NO_DELAY on
 sockets if HAPartition uses TCP
In-Reply-To: <8193195.1159407761620.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1707892.1159408121831.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3712?page=all ]

Brian Stansberry closed JBAS-3712.
----------------------------------

    Resolution: Done

> Use TCP_NO_DELAY on sockets if HAPartition uses TCP
> ---------------------------------------------------
>
>                 Key: JBAS-3712
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3712
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> HAPartition makes synchronous RPC calls; to improve latency we should disabling nagling by setting the new JGroups TCP.tcp_nodelay flag to true.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:48:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:48:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3711) Update to JGroups
	2.2.7.SP1
In-Reply-To: <16504659.1159383941683.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2819693.1159408121970.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3711?page=all ]

Brian Stansberry closed JBAS-3711.
----------------------------------

    Resolution: Done

> Update to JGroups 2.2.7.SP1
> ---------------------------
>
>                 Key: JBAS-3711
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3711
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>
> JGroups will release a 2.2.7.SP1 in the next day or so.  This will provide the ability to set TCP_NO_DELAY on TCP sockets. Integrate this so 4.0.5.GA can have reduced RPC call latency when using a TCP config.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:48:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-2272) Clustering unit test
 failures - TCP stack
Message-ID: <5771277.1159408122093.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2272?page=all ]

Brian Stansberry closed JBAS-2272.
----------------------------------

    Resolution: Done

> Clustering unit test failures - TCP stack
> -----------------------------------------
>
>                 Key: JBAS-2272
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2272
>             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-4.0.5.GA
>
>
> Resolve why we get numerous test case failures when using the tcp stack, even if as much as 2 seconds are allowed for state propagation across the cluster.

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:51:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:51:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-1761) Clustering unit
	test failures
Message-ID: <7756624.1159408301968.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry resolved JBAS-1761.
------------------------------------

    Resolution: Done

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-1761) Clustering unit
	test failures
Message-ID: <31959528.1159408482395.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-1761?page=comments#action_12344182 ] 
            
Brian Stansberry commented on JBAS-1761:
----------------------------------------

Final resolution of this involved the following:

1) Remove all up and down threads from the tc5-cluster.sar TCP stack, and all but one (up) thread from the cluster-service.xml stack.  Removes random latency I'd seen that caused failures of timing sensitive tests.
2) Added TCP.tcp_nodelay to cluster-service.xml TCP stack, where having nagling enabled was leading to timeout of a test that made >10,000 synchronous RPC calls.

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:42 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <26490043.1159408482748.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Comment: was deleted

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <10504089.1159408483049.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Comment: was deleted

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 21:54:43 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 21:54:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-1761) Clustering unit test
	failures
Message-ID: <17929216.1159408483348.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-1761?page=all ]

Brian Stansberry updated JBAS-1761:
-----------------------------------

    Comment: was deleted

> Clustering unit test failures
> -----------------------------
>
>                 Key: JBAS-1761
>                 URL: http://jira.jboss.com/jira/browse/JBAS-1761
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>         Environment: ant tests-clustering-all-stacks
> [starksm at banshee9100 testsuite]$ $JAVA_HOME/bin/java -version
> java version "1.4.2_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)
>            Reporter: Scott M Stark
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.0.5.GA
>
>         Attachments: 2005-05-02.21-59.tgz
>
>
> There are a number of clustering test failures using the TCP stack, and a couple using UDP that need to be resolved for the 4.0.2 release.
> Name	Tests	Errors	Failures	Time(s)
> ScopedAttrBasedTestCase(Default-TCP)	4	0	2	7.500
> ScopedTestCase(Default-TCP)	4	0	2	4.594
> SessionBasedConcurrentTestCase(Default-TCP)	2	0	1	9.766
> SimpleTestCase(Default-TCP)	3	0	2	64.532
> SimpleTestCase(Default-UDP)	3	0	1	64.359
> SimpleTestCase(SyncModeNUseJvm-TCP)	3	0	1	64.406
> SimpleTestCase(SyncModeNUseJvm-UDP)	3	0	1	64.562
> WebSessionTestCase(Default-TCP)	3	0	2	3.515

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:16:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 23:16:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3713) Full MBean lifecycle
 for HAPartition doesn't work
Message-ID: <26081580.1159413401705.JavaMail.jira@cloud.prod.atl2.jboss.com>

Full MBean lifecycle for HAPartition doesn't work
-------------------------------------------------

                 Key: JBAS-3713
                 URL: http://jira.jboss.com/jira/browse/JBAS-3713
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA


As reported by Noel Rocher in JBCLUSTER-55, HAPartition cycle : create -> start -> stop -> destroy -> create fails on 2nd create due to FarmMemberService throwing "org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'".

This is because superclass AbstractDeploymentScanner drops its ref to the deployer in destroyService().  The type passed to attribute Deployer is actually an ObjectName, so solution is to cache the ObjectName in FarmMemberService, and use it in createService() to re-call setDeployer() if the deployer is no longer available. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:21:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 23:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3713) Full MBean lifecycle
 for HAPartition doesn't work
In-Reply-To: <26081580.1159413401705.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14915566.1159413701622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3713?page=all ]

Brian Stansberry closed JBAS-3713.
----------------------------------

    Resolution: Done

> Full MBean lifecycle for HAPartition doesn't work
> -------------------------------------------------
>
>                 Key: JBAS-3713
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3713
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> As reported by Noel Rocher in JBCLUSTER-55, HAPartition cycle : create -> start -> stop -> destroy -> create fails on 2nd create due to FarmMemberService throwing "org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'".
> This is because superclass AbstractDeploymentScanner drops its ref to the deployer in destroyService().  The type passed to attribute Deployer is actually an ObjectName, so solution is to cache the ObjectName in FarmMemberService, and use it in createService() to re-call setDeployer() if the deployer is no longer available. 

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:27:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Wed, 27 Sep 2006 23:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCLUSTER-55) Full MBean cycle
 for HAPartition doesn't work
Message-ID: <14199710.1159414061672.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCLUSTER-55?page=all ]

Brian Stansberry resolved JBCLUSTER-55.
---------------------------------------

    Fix Version/s:     (was: Bugs)
       Resolution: Duplicate Issue
         Assignee: Brian Stansberry

Closing as duplicate; I recreated (and closed as fixed) the same issue in the AS project. Please report AS issues in the AS project.

> Full MBean cycle for HAPartition doesn't work
> ---------------------------------------------
>
>                 Key: JBCLUSTER-55
>                 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-55
>             Project: JBoss Clustering
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Noel Rocher
>         Assigned To: Brian Stansberry
>            Priority: Minor
>
> HAPartition cycle : create -> start -> stop -> destroy -> create.
> Here is a stack strace on 3.2:
> 09:03:03,523 ERROR [EntityContainer] Initialization failed jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB
> java.lang.NullPointerException
>         at org.jboss.ejb.EntityContainer.createService(EntityContainer.java:236)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> 09:03:03,523 WARN  [ServiceController] Problem creating service jboss.j2ee:jndiName=clustering/HTTPSession,service=EJB
> RuntimeMBeanException: java.lang.NullPointerException
> Cause: java.lang.NullPointerException
>         at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:82)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> Caused by: java.lang.NullPointerException
>         at org.jboss.ejb.EntityContainer.createService(EntityContainer.java:236)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         ... 66 more
> 09:03:03,533 ERROR [FarmMemberService] Initialization failed jboss:service=FarmMember,partition=DefaultPartition
> org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.createService(AbstractDeploymentScanner.java:233)
>         at org.jboss.ha.framework.server.FarmMemberService.createService(FarmMemberService.java:115)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> 09:03:03,543 WARN  [ServiceController] Problem creating service jboss:service=FarmMember,partition=DefaultPartition
> MBeanException: org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
> Cause: org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
>         at org.jboss.mx.server.ReflectedDispatcher.handleInvocationExceptions(ReflectedDispatcher.java:91)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:64)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:837)
>         at $Proxy56.create(Unknown Source)
>         at org.jboss.system.ServiceController.create(ServiceController.java:283)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at org.jboss.system.ServiceController.create(ServiceController.java:306)
>         at org.jboss.system.ServiceController.create(ServiceController.java:216)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:162)
>         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:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:61)
>         at org.jboss.mx.server.Invocation.dispatch(Invocation.java:53)
>         at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
>         at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:185)
>         at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:473)
>         at org.jboss.jmx.adaptor.control.Server.invokeOpByName(Server.java:234)
>         at org.jboss.jmx.adaptor.control.Server.invokeOp(Server.java:200)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.invokeOp(HtmlAdaptorServlet.java:241)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.processRequest(HtmlAdaptorServlet.java:79)
>         at org.jboss.jmx.adaptor.html.HtmlAdaptorServlet.doPost(HtmlAdaptorServlet.java:61)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:72)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.invoke(JBossSecurityMgrRealm.java:423)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
>         at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
>         at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
>         at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
>         at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
>         at java.lang.Thread.run(Thread.java:534)
> Caused by: org.jboss.system.MissingAttributeException: Missing attribute 'Deployer'
>         at org.jboss.deployment.scanner.AbstractDeploymentScanner.createService(AbstractDeploymentScanner.java:233)
>         at org.jboss.ha.framework.server.FarmMemberService.createService(FarmMemberService.java:115)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalCreate(ServiceMBeanSupport.java:237)
>         at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:219)
>         at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:324)
>         at org.jboss.mx.server.ReflectedDispatcher.dispatch(ReflectedDispatcher.java:60)
>         ... 66 more

-- 
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

        


From jira-events at jboss.com  Wed Sep 27 23:30:41 2006
From: jira-events at jboss.com (warren crossing (JIRA))
Date: Wed, 27 Sep 2006 23:30:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3714) EjbHome.create throws
 ClassCastException
Message-ID: <16949415.1159414241894.JavaMail.jira@cloud.prod.atl2.jboss.com>

EjbHome.create throws ClassCastException
----------------------------------------

                 Key: JBAS-3714
                 URL: http://jira.jboss.com/jira/browse/JBAS-3714
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: IIOP service
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
         Environment: Java 1.5.0_08
            Reporter: warren crossing
         Assigned To: Francisco Reverbel


Hello

Please have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974096#3974096 as this sums up my issue.

I have a jboss.log file and am happy to patch the source code and test/debug this issue.

It looks as though the IOR stream to object is returning a org.jacorb.orb.Reference which does not implement the beans Remote interface. 

I have stepped through the iiop EjbObjectServant code and IORFactory, the everything looks fine, no amount of changing jboss.xml ro standardjboss.xml makes any difference.

Why possibly could the reference returned by the DynamicIIOPStub.invoke not implement the Bean Remote interface? 

Any idea, or hist of where to look/debug?


-- 
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

        


From c15 at fullmailmarket.com  Thu Sep 28 02:02:31 2006
From: c15 at fullmailmarket.com (Carrier 179)
Date: Thu, 28 Sep 2006 02:02:31 -0400
Subject: [jboss-jira] Que el precio no se lo impida!
Message-ID: <200609280602.k8S62VU5031015@chief.prod.atl2.jboss.com>

An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-jira/attachments/20060928/3075ba60/attachment-0001.html 

From jira-events at jboss.com  Thu Sep 28 03:21:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 28 Sep 2006 03:21:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-331) Backport
 configuration for TCP's nagling from 2.4
In-Reply-To: <12248647.1159383041684.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23404675.1159428101476.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-331?page=all ]

Bela Ban resolved JGRP-331.
---------------------------

    Resolution: Done

> Backport configuration for TCP's nagling from 2.4
> -------------------------------------------------
>
>                 Key: JGRP-331
>                 URL: http://jira.jboss.com/jira/browse/JGRP-331
>             Project: JGroups
>          Issue Type: Task
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.2.7 SP1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:15:41 2006
From: jira-events at jboss.com (Ronald van Kuijk (JIRA))
Date: Thu, 28 Sep 2006 05:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBPM-732) remove process
 start link for processes without start task
In-Reply-To: <7236390.1155567977653.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17002937.1159434941482.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBPM-732?page=comments#action_12344196 ] 
            
Ronald van Kuijk commented on JBPM-732:
---------------------------------------

you can if you develop your own taskcontroler 

> remove process start link for processes without start task
> ----------------------------------------------------------
>
>                 Key: JBPM-732
>                 URL: http://jira.jboss.com/jira/browse/JBPM-732
>             Project: JBoss jBPM
>          Issue Type: Bug
>          Components: Web Interface
>            Reporter: Tom Baeyens
>         Assigned To: Tom Baeyens
>             Fix For: jBPM 3.2 alpha 2
>
>
> a check should be added to the start new process execution list on the home page that verifies if the process has a forms.xml.  if not, the start process link should not be 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

        


From jira-events at jboss.com  Thu Sep 28 05:27:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 05:27:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
Message-ID: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>

Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
--------------------------------------------------------------------------------------------

                 Key: JBRULES-505
                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: All
    Affects Versions: 3.0.4
         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
            Reporter: Matt Green
         Assigned To: Mark Proctor


SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
key                                                                                eventTypeDiscriminator
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58         net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57          net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56          net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()



-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:29:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 05:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12543486.1159435781512.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-505?page=all ]

Matt Green updated JBRULES-505:
-------------------------------

    Description: 
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
KEY, EVENTTYPEDISCRIMINATOR
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()



  was:
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
key                                                                                eventTypeDiscriminator
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58         net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57          net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56          net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()




> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:32:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 05:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24946684.1159435961888.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-505?page=all ]

Matt Green updated JBRULES-505:
-------------------------------

    Description: 
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
KEY, EVENTTYPEDISCRIMINATOR
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent

GLOBAL variable
eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()



  was:
SAMPLE CODE:
===============================================
package net.rockshore.rmf.rules

#list any import classes here.
import net.rockshore.rmf.entities.SubscriptionLocal;
import net.rockshore.rmf.entities.EventLocal;
import java.lang.String;

#declare any global variables here
global java.util.Collection resultsCollection;
global java.lang.String eventType;

rule "KeepSubscriptionsToEventType"
	
	when
		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
	then 
		resultsCollection.add(subscription);
		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
		
end

rule "DiscardSubscriptionsToWrongEventType"
	when
		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
	then 
		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
		retract (wrongSubscription);
end

===============================================

TEST DATA SET:
-------------------------

SubscriptionLocal objects asserted
KEY, EVENTTYPEDISCRIMINATOR
---------------------------------------------------------------------------------------------------------
5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent

eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"


PROBLEM DESCRIPTION:
-------------------------------------
When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.

Further, rule "KeepSubscriptionsToEventType" did not fire.

FURTHER ANALYSIS:
-------------------------------
If one rule OR the other is deleted then the remaining rule fires correctly.

If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.

The problem still occurs when eventType predicate is replaced with eventType.toString()




> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> GLOBAL variable
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:32:42 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Thu, 28 Sep 2006 05:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-330) Provide unblock()
 callback and make changes in FLUSH to call unblock()
In-Reply-To: <10804580.1159360721663.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9069460.1159435962133.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-330?page=all ]

Bela Ban resolved JGRP-330.
---------------------------

    Resolution: Done

block() and unblock() are called correctly

> Provide unblock() callback and make changes in FLUSH to call unblock()
> ----------------------------------------------------------------------
>
>                 Key: JGRP-330
>                 URL: http://jira.jboss.com/jira/browse/JGRP-330
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.4
>
>
> #1 New callback unblock() in ExtendedMembershipListener (new interface). ExtendedReceiver now extends ExtendedMembershipListener too. (These interfaces will all be merged into 1 in 3.0).
> #2 Make changes in FLUSH to (a) call unblock() on FLUSH completion if we use the push mode, or (b) add an UnblockEvent to the receiver queue if we use the pull mode

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 05:35:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Thu, 28 Sep 2006 05:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3714) EjbHome.create throws
 ClassCastException
In-Reply-To: <16949415.1159414241894.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19970109.1159436141792.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3714?page=all ]

Adrian Brock closed JBAS-3714.
------------------------------

    Resolution: Incomplete Description
      Assignee:     (was: Francisco Reverbel)

Just because you don't get an answer in the forums
it does not mean it is a bug report.

Also you should not use the development forums to ask for help.
Development forums are to discuss solutions to problems, not ask
for help on problems.

I'm going to move your post to the EJB user forum and ignore it.
You cannot use bug reports to jump the help queue!
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHelp

> EjbHome.create throws ClassCastException
> ----------------------------------------
>
>                 Key: JBAS-3714
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3714
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: IIOP service
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>         Environment: Java 1.5.0_08
>            Reporter: warren crossing
>
> Hello
> Please have a look at http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3974096#3974096 as this sums up my issue.
> I have a jboss.log file and am happy to patch the source code and test/debug this issue.
> It looks as though the IOR stream to object is returning a org.jacorb.orb.Reference which does not implement the beans Remote interface. 
> I have stepped through the iiop EjbObjectServant code and IORFactory, the everything looks fine, no amount of changing jboss.xml ro standardjboss.xml makes any difference.
> Why possibly could the reference returned by the DynamicIIOPStub.invoke not implement the Bean Remote interface? 
> Any idea, or hist of where to look/debug?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 06:32:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 06:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
Message-ID: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>

1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
----------------------------------------------------------------------------------

                 Key: JBAS-3715
                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Security, Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-42.0.2.ELsmp 
OS Arch i386 
            Reporter: Dimitris Andreadis
         Assigned To: Anil Saldhana
             Fix For: JBossAS-4.0.5.GA


testSRPLoginWithAuxChallenge Failure

Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.extensions.TestSetup.run(TestSetup.java:23)

The same test passes with Sun Jdk1.4 but I believe this is due to 

jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
   local_policy.jar
   US_export_policy.jar

Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 06:36:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 06:36:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-86) Identify what QA and
 unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6829945.1159439801742.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-86?page=all ]

Mark Little reassigned JBESB-86:
--------------------------------

    Assignee: Mark Little  (was: Tom Fennelly)

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 06:45:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 06:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22799147.1159440341523.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little updated JBESB-104:
------------------------------

    Priority: Blocker  (was: Critical)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Daniel Brum
>            Priority: Blocker
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 06:48:42 2006
From: jira-events at jboss.com (Thomas Diesler (JIRA))
Date: Thu, 28 Sep 2006 06:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3710) WebServices leaking
	redeployment
In-Reply-To: <30917021.1159380401766.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9887230.1159440522167.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3710?page=all ]

Thomas Diesler resolved JBAS-3710.
----------------------------------

    Resolution: Done

Done. I tested jbossws and jbossas testsuite with jdk1.5


> WebServices leaking redeployment
> --------------------------------
>
>                 Key: JBAS-3710
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3710
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Clebert Suconic
>         Assigned To: Thomas Diesler
>            Priority: Blocker
>             Fix For: JBossAS-4.0.5.GA
>
>
> JBWS-1228 has the description for this bug

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 06:48:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 06:48:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3524887.1159440522364.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little reassigned JBESB-104:
---------------------------------

    Assignee: Kevin Conner  (was: Daniel Brum)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>            Priority: Blocker
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:00:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3716) failed
 org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
Message-ID: <2246804.1159441241688.JavaMail.jira@cloud.prod.atl2.jboss.com>

failed org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
-----------------------------------------------------------------------------

                 Key: JBAS-3716
                 URL: http://jira.jboss.com/jira/browse/JBAS-3716
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: Test Suite
         Environment: Java Version 1.4.2_11 
Java Vendor BEA Systems, Inc. 
Java VM Name BEA JRockit(R) 
Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
Java VM Info  
OS Name Linux 
OS Version 2.6.9-42.0.2.ELsmp 
OS Arch i386 

            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.5.GA


testStringCharArrayCredential
Failure
N/A
junit.framework.AssertionFailedError
	at org.jboss.test.security.test.JaasSecurityManagerUnitTestCase.testStringCharArrayCredential(JaasSecurityManagerUnitTestCase.java:79)
	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Thu Sep 28 07:00:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:00:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-123) Remove hardcoded
	class names
In-Reply-To: <1140887.1155045312458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32194858.1159441241838.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-123?page=all ]

Mark Little reassigned JBESB-123:
---------------------------------

    Assignee: Mark Little  (was: Daniel Brum)

> Remove hardcoded class names
> ----------------------------
>
>                 Key: JBESB-123
>                 URL: http://jira.jboss.com/jira/browse/JBESB-123
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
>       Class oCls = Class.forName("org.jboss.soa.esb.util.BobjStdDTO");

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:06:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3716) failed
 org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
In-Reply-To: <2246804.1159441241688.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10523304.1159441602140.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3716?page=all ]

Dimitris Andreadis closed JBAS-3716.
------------------------------------

    Resolution: Done

Fixed the order.

> failed org.jboss.test.security.test.JaasSecurityManagerUnitTestCase (jrockit)
> -----------------------------------------------------------------------------
>
>                 Key: JBAS-3716
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3716
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> testStringCharArrayCredential
> Failure
> N/A
> junit.framework.AssertionFailedError
> 	at org.jboss.test.security.test.JaasSecurityManagerUnitTestCase.testStringCharArrayCredential(JaasSecurityManagerUnitTestCase.java:79)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown 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

        


From jira-events at jboss.com  Thu Sep 28 07:06:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-123) Remove hardcoded
	class names
In-Reply-To: <1140887.1155045312458.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20384745.1159441602293.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-123?page=all ]

Mark Little closed JBESB-123.
-----------------------------

    Resolution: Done

> Remove hardcoded class names
> ----------------------------
>
>                 Key: JBESB-123
>                 URL: http://jira.jboss.com/jira/browse/JBESB-123
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 5 minutes
>  Remaining Estimate: 0 minutes
>
>       Class oCls = Class.forName("org.jboss.soa.esb.util.BobjStdDTO");

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:06:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:06:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-145) Automate the
 trailblazer as part of QA
In-Reply-To: <6932816.1158761999738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23293927.1159441602483.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-145?page=all ]

Mark Little reassigned JBESB-145:
---------------------------------

    Assignee: Jason Lenhart  (was: Daniel Brum)

> Automate the trailblazer as part of QA
> --------------------------------------
>
>                 Key: JBESB-145
>                 URL: http://jira.jboss.com/jira/browse/JBESB-145
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Examples, Testing
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Jason Lenhart
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:08:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-27) Manage the wiki
 pages for consistency and traversal
Message-ID: <31737211.1159441721672.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-27?page=comments#action_12344204 ] 
            
Mark Little commented on JBESB-27:
----------------------------------

I think we are OK at the moment. This is going to be an on-going task anyway, so I'd like to close it as DONE.

> Manage the wiki pages for consistency and traversal
> ---------------------------------------------------
>
>                 Key: JBESB-27
>                 URL: http://jira.jboss.com/jira/browse/JBESB-27
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Minor
>             Fix For: 4.0
>
>
> We need to make sure that the JBossESB wiki pages are up-to-date with respect to what happens on the forums and that they all have a consistent look-and-feel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:10:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <9108980.1159441842314.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-2299?page=all ]

Dimitris Andreadis updated JBAS-2299:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.GA)

It's too late for 3rd party updates at this point, so let's revisit this in the next release. Thanks Clebert!

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: Data.txt, SampleApp.ear
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:10:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10238028.1159441842440.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3699?page=all ]

Dimitris Andreadis updated JBAS-3699:
-------------------------------------

    Comment: was deleted

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:13:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:13:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-151) Does the
 ParamsRepository
 approach conflict with, or support, the PropertyManager?
Message-ID: <30050711.1159442021527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Does the ParamsRepository approach conflict with, or support, the PropertyManager?
----------------------------------------------------------------------------------

                 Key: JBESB-151
                 URL: http://jira.jboss.com/jira/browse/JBESB-151
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:13:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 07:13:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19541705.1159442021655.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3699?page=comments#action_12344206 ] 
            
Dimitris Andreadis commented on JBAS-3699:
------------------------------------------

Re-enable the ws tests using the new jbossws-1.0.3SP1 update to see if it fixes the memory leak.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             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 indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:16:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:16:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-73) Work out which
 classes and interfaces are private versus public
Message-ID: <4764357.1159442201788.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-73?page=comments#action_12344207 ] 
            
Mark Little commented on JBESB-73:
----------------------------------

I think ParamFileRepository can be made internal, since all users (except tests) access it via the factory.

> Work out which classes and interfaces are private versus public
> ---------------------------------------------------------------
>
>                 Key: JBESB-73
>                 URL: http://jira.jboss.com/jira/browse/JBESB-73
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:19:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:19:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-73) Work out which
 classes and interfaces are private versus public
Message-ID: <2213037.1159442381611.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-73?page=comments#action_12344208 ] 
            
Mark Little commented on JBESB-73:
----------------------------------

StreamUtils could likewise be moved because it is only used by ParamFileRepository.

> Work out which classes and interfaces are private versus public
> ---------------------------------------------------------------
>
>                 Key: JBESB-73
>                 URL: http://jira.jboss.com/jira/browse/JBESB-73
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Esteban Schifman
>             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:22:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:22:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-64) General tidy-up of
	code
Message-ID: <214473.1159442561687.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-64?page=comments#action_12344210 ] 
            
Mark Little commented on JBESB-64:
----------------------------------

Remove I from the front of interface names.

> General tidy-up of code
> -----------------------
>
>                 Key: JBESB-64
>                 URL: http://jira.jboss.com/jira/browse/JBESB-64
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Arvinder Singh
>            Priority: Minor
>             Fix For: 4.0
>
>
> 1) Naming Conventions, e.g IbatchHandler -> IBatchHandler
> 2) Property naming conventions
> 3) Categorize exceptions instead of just using Exception, e.g ConnectException, etc
> 4) import specific classes not * 

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:28:41 2006
From: jira-events at jboss.com (Mark Proctor (JIRA))
Date: Thu, 28 Sep 2006 07:28:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7704209.1159442921712.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-505?page=comments#action_12344211 ] 
            
Mark Proctor commented on JBRULES-505:
--------------------------------------

btw that example uses a "return value" instead of a "predicate". Any chance you could make a self contained test, otherwise it will be some time before we get round to testing this.

> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> GLOBAL variable
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:28:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:28:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-152) Restructure the
	action package
Message-ID: <27906295.1159442921823.JavaMail.jira@cloud.prod.atl2.jboss.com>

Restructure the action package
------------------------------

                 Key: JBESB-152
                 URL: http://jira.jboss.com/jira/browse/JBESB-152
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Thu Sep 28 07:34:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:34:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-153) Make all
 configuration attribute names have consistent format
Message-ID: <25928255.1159443281619.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make all configuration attribute names have consistent format
-------------------------------------------------------------

                 Key: JBESB-153
                 URL: http://jira.jboss.com/jira/browse/JBESB-153
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


org.jboss.soa.esb as the root of all names.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:40:41 2006
From: jira-events at jboss.com (Matt Green (JIRA))
Date: Thu, 28 Sep 2006 07:40:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBRULES-505) Using a GLOBAL
 value in
 predicates in more than one rule - rule fails to evaluate correctly.
In-Reply-To: <25122251.1159435661732.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9170219.1159443641950.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBRULES-505?page=comments#action_12344212 ] 
            
Matt Green commented on JBRULES-505:
------------------------------------

OK, I'll put together some code and make it selfcontained. I will have to simplify the asserted objects as they are EJBs! I'll replace with simple Java classes.

> Using a GLOBAL value in predicates in more than one rule - rule fails to evaluate correctly.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBRULES-505
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-505
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: All
>    Affects Versions: 3.0.4
>         Environment: Windows XP, JBoss 4.0.3SP1, JRules3.0.4, PackageBuilderConfiguration.JANINO
>            Reporter: Matt Green
>         Assigned To: Mark Proctor
>
> SAMPLE CODE:
> ===============================================
> package net.rockshore.rmf.rules
> #list any import classes here.
> import net.rockshore.rmf.entities.SubscriptionLocal;
> import net.rockshore.rmf.entities.EventLocal;
> import java.lang.String;
> #declare any global variables here
> global java.util.Collection resultsCollection;
> global java.lang.String eventType;
> rule "KeepSubscriptionsToEventType"
> 	
> 	when
> 		subscription : SubscriptionLocal (eventTypeDiscriminator == (eventType))
> 	then 
> 		resultsCollection.add(subscription);
> 		System.out.println("Keeping Subscription:" + subscription + " is of type:" + eventType);
> 		
> end
> rule "DiscardSubscriptionsToWrongEventType"
> 	when
> 		wrongSubscription : SubscriptionLocal (eventTypeDiscriminator != (eventType))
> 	then 
> 		System.out.println("Discarding Subscription:" + wrongSubscription + " NOT of type:" + eventType);
> 		retract (wrongSubscription);
> end
> ===============================================
> TEST DATA SET:
> -------------------------
> SubscriptionLocal objects asserted
> KEY, EVENTTYPEDISCRIMINATOR
> ---------------------------------------------------------------------------------------------------------
> 5c4o12-mexdpy-esmukytr-1-esmx439o-58 ,        net.rockshore.rmf.entities.events.business.TravelAlertEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-57 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> 5c4o12-mexdpy-esmukytr-1-esmx438t-56 ,         net.rockshore.rmf.entities.events.business.FlightDelayEvent
> GLOBAL variable
> eventType = "net.rockshore.rmf.entities.events.business.FlightDelayEvent"
> PROBLEM DESCRIPTION:
> -------------------------------------
> When firing the above rules with data shown above, the result shows that "DiscardSubscriptionsToWrongEventType" rule was fired for Subscriptions with keys ending 57 and 56. This is the wrong way round as that rule should have fired only with Subscription 58.
> Further, rule "KeepSubscriptionsToEventType" did not fire.
> FURTHER ANALYSIS:
> -------------------------------
> If one rule OR the other is deleted then the remaining rule fires correctly.
> If both rules have the predicate replaced with a String literal "net.rockshore.rmf.entities.events.business.FlightDelayEvent" then both rules fire correctly.
> The problem still occurs when eventType predicate is replaced with eventType.toString()

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 07:49:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 07:49:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBESB-111) JMX support
In-Reply-To: <22340669.1154530933941.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5829812.1159444181558.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-111?page=all ]

Mark Little updated JBESB-111:
------------------------------

    Fix Version/s: 4.1
                       (was: 4.0)

> JMX support
> -----------
>
>                 Key: JBESB-111
>                 URL: http://jira.jboss.com/jira/browse/JBESB-111
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1
>            Reporter: Kurt Stam
>         Assigned To: Mohit Keswani
>            Priority: Minor
>             Fix For: 4.1
>
>
> Support for JMX (the one build into java5) so you can look at the pool
> and reset connection 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

        


From jira-events at jboss.com  Thu Sep 28 08:07:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Thu, 28 Sep 2006 08:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-137) JTS
 PropagationContextManager does too much
Message-ID: <5466271.1159445261544.JavaMail.jira@cloud.prod.atl2.jboss.com>

JTS PropagationContextManager does too much
-------------------------------------------

                 Key: JBTM-137
                 URL: http://jira.jboss.com/jira/browse/JBTM-137
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.6


We should only need to send a reference to the current transaction and not the full context. Also means we don't need to do interposition, just resume.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 08:43:41 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Thu, 28 Sep 2006 08:43:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-154) Change configuration
 for FTP listeners/actions to avoid need to replicate FTP parameters
Message-ID: <4026448.1159447421501.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change configuration for FTP listeners/actions to avoid need to replicate FTP parameters
----------------------------------------------------------------------------------------

                 Key: JBESB-154
                 URL: http://jira.jboss.com/jira/browse/JBESB-154
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0
            Reporter: Esteban Schifman
         Assigned To: Esteban Schifman
            Priority: Minor


FTP server/username/password are needed both by the RemoteDirectoryPoller, and the FTP classes
As it stands now, they need to be replicated in the xml configuration file for listeners and actions.  This is not appropriate and we should find ways to avoid this need.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:07:41 2006
From: jira-events at jboss.com (David Fuelling (JIRA))
Date: Thu, 28 Sep 2006 09:07:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMAIL-250)
 MailUserImpl.getAliases(..)
 throws an NPE if there is no mailbox for a given alias to check.
Message-ID: <3262166.1159448861705.JavaMail.jira@cloud.prod.atl2.jboss.com>

MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.
--------------------------------------------------------------------------------------------

                 Key: JBMAIL-250
                 URL: http://jira.jboss.com/jira/browse/JBMAIL-250
             Project: JBoss Mail
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Mail Server APIs
    Affects Versions: 1.0-M5, 1.0-RC1
         Environment: WinXp, Jdk 1.5
            Reporter: David Fuelling
         Assigned To: Andrew Oliver
            Priority: Minor


MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).

Here is my patch:



Index: MailSenderImpl.java
===================================================================
RCS file: /cvsroot/jboss/jboss-mail/src/java/org/jboss/mail/userapi/MailSenderImpl.java,v
retrieving revision 1.13
diff -u -r1.13 MailSenderImpl.java
--- MailSenderImpl.java	13 Jun 2006 23:53:04 -0000	1.13
+++ MailSenderImpl.java	28 Sep 2006 13:05:06 -0000
@@ -273,6 +273,9 @@
     @Tx(TxType.REQUIRED)
     public List<String> getAliases(String user) {
         Mailbox box = this.mailboxService.getMailboxByAlias(user);
+        if(box == null)
+        	return new ArrayList<String>(); //No Aliases exist for this user.
+        
         Collection<Alias> a = box.getAliases();
         List<String> l = new ArrayList<String>(a.size());
         Iterator<Alias> i = a.iterator();

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:10:41 2006
From: jira-events at jboss.com (David Fuelling (JIRA))
Date: Thu, 28 Sep 2006 09:10:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMAIL-250)
 MailUserImpl.getAliases(..)
 throws an NPE if there is no mailbox for a given alias to check.
In-Reply-To: <3262166.1159448861705.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14356141.1159449041981.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMAIL-250?page=all ]

David Fuelling updated JBMAIL-250:
----------------------------------

    Attachment: MailSenderImpl_patch..txt

This is the patch file for this issue.

> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMAIL-250
>                 URL: http://jira.jboss.com/jira/browse/JBMAIL-250
>             Project: JBoss Mail
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Mail Server APIs
>    Affects Versions: 1.0-M5, 1.0-RC1
>         Environment: WinXp, Jdk 1.5
>            Reporter: David Fuelling
>         Assigned To: Andrew Oliver
>            Priority: Minor
>         Attachments: MailSenderImpl_patch..txt
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).
> Here is my patch:
> Index: MailSenderImpl.java
> ===================================================================
> RCS file: /cvsroot/jboss/jboss-mail/src/java/org/jboss/mail/userapi/MailSenderImpl.java,v
> retrieving revision 1.13
> diff -u -r1.13 MailSenderImpl.java
> --- MailSenderImpl.java	13 Jun 2006 23:53:04 -0000	1.13
> +++ MailSenderImpl.java	28 Sep 2006 13:05:06 -0000
> @@ -273,6 +273,9 @@
>      @Tx(TxType.REQUIRED)
>      public List<String> getAliases(String user) {
>          Mailbox box = this.mailboxService.getMailboxByAlias(user);
> +        if(box == null)
> +        	return new ArrayList<String>(); //No Aliases exist for this user.
> +        
>          Collection<Alias> a = box.getAliases();
>          List<String> l = new ArrayList<String>(a.size());
>          Iterator<Alias> i = a.iterator();

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:10:42 2006
From: jira-events at jboss.com (Luca Stancapiano (JIRA))
Date: Thu, 28 Sep 2006 09:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16298248.1159449042466.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3690?page=comments#action_12344218 ] 
            
Luca Stancapiano commented on JBAS-3690:
----------------------------------------

in that test, JSESSIONIDSSO seems to not be catched......after the search of cookies , test fails because is not there that cookie

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 09:10:42 2006
From: jira-events at jboss.com (David Fuelling (JIRA))
Date: Thu, 28 Sep 2006 09:10:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMAIL-250)
 MailUserImpl.getAliases(..)
 throws an NPE if there is no mailbox for a given alias to check.
In-Reply-To: <3262166.1159448861705.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22115920.1159449042658.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMAIL-250?page=all ]

David Fuelling updated JBMAIL-250:
----------------------------------

    Description: 
MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).

See the attached file for proposed patch.

  was:
MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).

Here is my patch:



Index: MailSenderImpl.java
===================================================================
RCS file: /cvsroot/jboss/jboss-mail/src/java/org/jboss/mail/userapi/MailSenderImpl.java,v
retrieving revision 1.13
diff -u -r1.13 MailSenderImpl.java
--- MailSenderImpl.java	13 Jun 2006 23:53:04 -0000	1.13
+++ MailSenderImpl.java	28 Sep 2006 13:05:06 -0000
@@ -273,6 +273,9 @@
     @Tx(TxType.REQUIRED)
     public List<String> getAliases(String user) {
         Mailbox box = this.mailboxService.getMailboxByAlias(user);
+        if(box == null)
+        	return new ArrayList<String>(); //No Aliases exist for this user.
+        
         Collection<Alias> a = box.getAliases();
         List<String> l = new ArrayList<String>(a.size());
         Iterator<Alias> i = a.iterator();


> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.
> --------------------------------------------------------------------------------------------
>
>                 Key: JBMAIL-250
>                 URL: http://jira.jboss.com/jira/browse/JBMAIL-250
>             Project: JBoss Mail
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Mail Server APIs
>    Affects Versions: 1.0-M5, 1.0-RC1
>         Environment: WinXp, Jdk 1.5
>            Reporter: David Fuelling
>         Assigned To: Andrew Oliver
>            Priority: Minor
>         Attachments: MailSenderImpl_patch..txt
>
>   Original Estimate: 0 minutes
>  Remaining Estimate: 0 minutes
>
> MailUserImpl.getAliases(..) throws an NPE if there is no mailbox for a given alias to check.  Instead, the function should simply check if the mbox is null, and if so, simply return an empty list of aliases (i.e., there are no aliases for this user).
> See the attached file for proposed patch.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:24:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 28 Sep 2006 10:24:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3690) testsuite on web
 about single sign on wrong (I think...)
In-Reply-To: <1485425.1159044901359.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4499762.1159453481937.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3690?page=comments#action_12344219 ] 
            
Brian Stansberry commented on JBAS-3690:
----------------------------------------

If you want to discuss the test, please open a forum thread on http://www.jboss.com/index.html?module=bb&op=viewforum&f=64.  If your JIRA issue includes "(I think...)" that's a good sign you shouldn't open a JIRA but rather a forum thread.

> testsuite on web about single sign on wrong (I think...)
> --------------------------------------------------------
>
>                 Key: JBAS-3690
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3690
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>    Affects Versions: JBossAS-4.0.4.GA
>         Environment: fedora core 5 with eclipse 3.2 and jdk 1.5.7
>            Reporter: Luca Stancapiano
>         Assigned To: Brian Stansberry
>
> on org.jboss.test.web.test.SSOBaseCase row 99 in jboss 4.0.4GA .....instead of JSESSIONIDSSO param of cookie, should to be used JSESSIONID .....that param is not recognized by web application

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:29:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 28 Sep 2006 10:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <388796.1159453781607.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344220 ] 
            
Anil Saldhana commented on JBAS-3715:
-------------------------------------

Remember the "Unlimited Strength Crypto" that needs to be downloaded for the VM?  We did for Sun VM?

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:32:42 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Thu, 28 Sep 2006 10:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-2299) OutOfMemory error
 when repetatively deploying and undeploying with 10 minute interval
Message-ID: <5409028.1159453962270.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-2299?page=comments#action_12344221 ] 
            
Clebert Suconic commented on JBAS-2299:
---------------------------------------

We could update BeanUtils to use SoftReferences on reflection.
The easiest way to do this would be to use PersistentReference (a package I created for JBossSerialization) and recreate reflection automatically in case the SoftReference is released earlier than expected.

We could contribute PersistentReferences to Apache and use it on BeanUtils. (But I don't know if we want to do this. I know we could since I"m the author of the package)

http://fisheye.jboss.org/browse/JBoss/jboss-serialization/src/org/jboss/serial/references/PersistentReference.java?r=1.3

> OutOfMemory error when repetatively deploying and undeploying with 10 minute interval
> -------------------------------------------------------------------------------------
>
>                 Key: JBAS-2299
>                 URL: http://jira.jboss.com/jira/browse/JBAS-2299
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Deployment services
>    Affects Versions:  JBossAS-4.0.3RC2
>         Environment: WinXP SP2, JBoss 4.0.3RC2, JDK 1.4.2_07
>            Reporter: Amar Syed
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>         Attachments: Data.txt, SampleApp.ear
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> Using a manual copy and delete mechanism with the server\default\deploy folder the sample ear (attached) caused an outofmemory error eventually after 90 repetitions.
> The min and max heap settings were configured as : -Xms128m -Xmx512m
> The time delay after dropping/deploying the ear at each repetition was set to 10 minutes after which the ear is deleted/undeployed followed by a 10 second sleep till the next deploy cycle.
> I find this behaviour strange because http://jira.jboss.com/jira/browse/JBAS-1319 is supposed to have fixed this issue.
> The lines from the server.log surrounding the java.lang.OutOfMemoryError are as follows:
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> 2005-09-24 06:04:31,413 DEBUG [org.jboss.mx.loading.RepositoryClassLoader] setRepository, repository=org.jboss.mx.loading.HeirarchicalLoaderRepository3 at e51e50, cl=org.jboss.mx.loading.UnifiedClassLoader3 at c90207{ url=null ,addedOrder=0}
> 2005-09-24 06:04:33,057 ERROR [org.apache.commons.digester.Digester] Begin event threw error
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] StandardWrapper.Throwable
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,057 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/XMPVXE0Partion/VXE1_ContentTestService]] Servlet /XMPVXE0Partion/VXE1_ContentTestService threw load() exception
> java.lang.OutOfMemoryError
> 2005-09-24 06:04:33,072 DEBUG [org.jboss.mx.loading.UnifiedClassLoader] New jmx UCL with url null
> The following two jars were added to the server\default\lib folder. 
> commons-validator.jar --- version 1.1.3
> struts.jar ---- version 1.2.4

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:32:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 10:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2978434.1159453962435.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344222 ] 
            
Dimitris Andreadis commented on JBAS-3715:
------------------------------------------

I remember you gave me a link to download the jars :)

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:38:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Thu, 28 Sep 2006 10:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3338126.1159454321899.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344223 ] 
            
Anil Saldhana commented on JBAS-3715:
-------------------------------------

http://java.sun.com/products/jce/index-14.html#UnlimitedDownload
This is for JDK4.  Should work on JRockit also as per http://dev.project.net/trac/pnet/wiki/InstallationGuides

(Q. Where do I get the unlimited strength encryption JCE Policy files for JRockit? A. Use the Sun ones for the appropriate version of JRockit (e.g. 1.4.2 policy files))

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Anil Saldhana
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 10:47:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Thu, 28 Sep 2006 10:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6361975.1159454861866.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3715?page=all ]

Dimitris Andreadis reassigned JBAS-3715:
----------------------------------------

    Assignee: Rajesh Rajasekaran  (was: Anil Saldhana)

Rajesh should take it from here, thanks Anil!

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 11:05:41 2006
From: jira-events at jboss.com (Rajesh Rajasekaran (JIRA))
Date: Thu, 28 Sep 2006 11:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11574974.1159455941554.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3715?page=comments#action_12344225 ] 
            
Rajesh Rajasekaran commented on JBAS-3715:
------------------------------------------

Have updated the unlimited strength encryption files. will wait for the next run and close the issue once test passes

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 11:35:41 2006
From: jira-events at jboss.com (Thomas Klute (JIRA))
Date: Thu, 28 Sep 2006 11:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-758) DbPersistenceService
 needs update for new Hibernate version
Message-ID: <8388143.1159457741580.JavaMail.jira@cloud.prod.atl2.jboss.com>

DbPersistenceService needs update for new Hibernate version
-----------------------------------------------------------

                 Key: JBPM-758
                 URL: http://jira.jboss.com/jira/browse/JBPM-758
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
         Environment: jboss AS 4.0.4, hibernate 3.1 or hibernate 3.2
            Reporter: Thomas Klute
         Assigned To: Tom Baeyens
             Fix For: jBPM 3.1.3


Release of JDBC connections changed with hibernate version > 3.0.
DbPersistenceService now throws exception when trying to close a hibernate session (because in was closed automatically when the transaction committed).
The exception happens every few seconds when using the jbpm scheduler-service.
See below for stack trace.

See http://www.hibernate.org/250.html#A31 for a detailed description of hibernate-changes regarding JDBC connections.

FYI: The exception does not roll back the transaction, because it has already been committed. 
Please adapt the code to the new hibernate behaviour. Maybe just comment out the "throw" of the exception.
I have no idea what code would work with old _and_ new hibernate versions.
We just got the problem integrating jbpm into a jboss AS 4.0.4 using hibernate 3.2.


...
2006-09-28 16:11:53,996 DEBUG [org.jbpm.persistence.db.DbPersistenceService] creating hibernate session
2006-09-28 16:11:53,998 DEBUG [org.hibernate.jdbc.JDBCContext] TransactionFactory reported no active transaction; Synchronization not registered
2006-09-28 16:11:53,998 DEBUG [org.hibernate.impl.SessionImpl] opened session at timestamp: 4749118316527616
2006-09-28 16:11:53,998 DEBUG [org.jbpm.persistence.db.DbPersistenceService] beginning hibernate transaction
2006-09-28 16:11:53,998 DEBUG [org.hibernate.transaction.JTATransaction] Looking for UserTransaction under: UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] Obtained UserTransaction
2006-09-28 16:11:53,999 DEBUG [org.hibernate.transaction.JTATransaction] begin
2006-09-28 16:11:54,000 DEBUG [org.hibernate.transaction.JTATransaction] Began a new JTA transaction
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.JDBCContext] successfully registered Synchronization
2006-09-28 16:11:54,000 DEBUG [org.jbpm.scheduler.impl.SchedulerThread] checking for timers
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
2006-09-28 16:11:54,000 DEBUG [org.hibernate.jdbc.ConnectionManager] opening JDBC connection
2006-09-28 16:11:54,000 DEBUG [org.hibernate.SQL] select timer0_.ID_ as col_0_0_ from JBPM_TIMER timer0_ where (timer0_.EXCEPTION_ is null) and timer0_.ISSUSPENDED_<>1 order by timer0_.DUEDATE_ asc
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to open ResultSet (open ResultSets: 0, globally: 0)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] exhausted results
2006-09-28 16:11:54,001 DEBUG [org.hibernate.impl.IteratorImpl] closing iterator
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close ResultSet (open ResultSets: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.AbstractBatcher] about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] aggressively releasing JDBC connection
2006-09-28 16:11:54,001 DEBUG [org.hibernate.jdbc.ConnectionManager] releasing JDBC connection [ (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]
2006-09-28 16:11:54,001 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
2006-09-28 16:11:54,002 DEBUG [org.jbpm.svc.Services] closing service 'persistence': org.jbpm.persistence.db.DbPersistenceService at 15a9173
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] committing hibernate transaction
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] commit
2006-09-28 16:11:54,002 DEBUG [org.hibernate.transaction.JTATransaction] Committed JTA UserTransaction
2006-09-28 16:11:54,002 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR] org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.svc.Services.close(Services.java:211)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.JbpmContext.close(JbpmContext.java:139)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
2006-09-28 16:11:54,002 ERROR [STDERR]  at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
2006-09-28 16:11:54,003 ERROR [STDERR] Caused by: org.hibernate.SessionException: Session was already closed
2006-09-28 16:11:54,003 ERROR [STDERR]  at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
2006-09-28 16:11:54,003 ERROR [STDERR]  at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
2006-09-28 16:11:54,003 ERROR [STDERR]  ... 4 more
2006-09-28 16:11:54,003 ERROR [org.jbpm.svc.Services] problem closing service 'persistence'
org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
        at org.jbpm.svc.Services.close(Services.java:211)
        at org.jbpm.JbpmContext.close(JbpmContext.java:139)
        at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
        at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.hibernate.SessionException: Session was already closed
        at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
        ... 4 more
2006-09-28 16:11:54,003 INFO  [org.jbpm.scheduler.impl.SchedulerThread] runtime exception while executing timers
org.jbpm.JbpmException: problem closing services {persistence=org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session}
        at org.jbpm.svc.Services.close(Services.java:223)
        at org.jbpm.JbpmContext.close(JbpmContext.java:139)
        at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
        at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
Caused by: org.jbpm.persistence.JbpmPersistenceException: couldn't close hibernate session
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:191)
        at org.jbpm.svc.Services.close(Services.java:211)
        ... 3 more
Caused by: org.hibernate.SessionException: Session was already closed
        at org.hibernate.impl.SessionImpl.close(SessionImpl.java:277)
        at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:189)
        ... 4 more


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 11:38:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Thu, 28 Sep 2006 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3717) correct TCL should
 be used before starting entity PMs
Message-ID: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>

correct TCL should be used before starting entity PMs
-----------------------------------------------------

                 Key: JBAS-3717
                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Alexey Loubyansky
         Assigned To: Alexey Loubyansky


In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
   protected void startService() throws Exception
   {
      // before EntityContainer returns from the startService, its PM should be usable
      ListIterator iter = containerOrdering.listIterator();
      while( iter.hasNext() )
      {
         Container con = (Container) iter.next();
         if(con.getBeanMetaData().isEntity())
         {
            ClassLoader oldCl = SecurityActions.getContextClassLoader();
            SecurityActions.setContextClassLoader(con.getClassLoader());

            try
            {
               ((EntityContainer)con).getPersistenceManager().start();
            }
            finally
            {
               // Reset classloader
               SecurityActions.setContextClassLoader(oldCl);
            }
         }
      }
...

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-27) Integrate Web
 Services transactions component with JBoss 4
Message-ID: <23932694.1159459361787.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-27?page=comments#action_12344226 ] 
            
Kevin Conner commented on JBTM-27:
----------------------------------

The web services component was actually integrated in release 4.2.1.

> Integrate Web Services transactions component with JBoss 4
> ----------------------------------------------------------
>
>                 Key: JBTM-27
>                 URL: http://jira.jboss.com/jira/browse/JBTM-27
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-27) Integrate Web Services
 transactions component with JBoss 4
Message-ID: <28612186.1159459361949.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-27?page=all ]

Kevin Conner closed JBTM-27.
----------------------------

    Fix Version/s: 4.2.1
                       (was: 4.2.2)
       Resolution: Done

> Integrate Web Services transactions component with JBoss 4
> ----------------------------------------------------------
>
>                 Key: JBTM-27
>                 URL: http://jira.jboss.com/jira/browse/JBTM-27
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: WS-T Implementation
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:14:43 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:14:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-117) release notes for
 JTS talk about context interceptor
In-Reply-To: <4031051.1155223512756.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3034363.1159460083461.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-117?page=all ]

Kevin Conner resolved JBTM-117.
-------------------------------

    Resolution: Done

> release notes for JTS talk about context interceptor
> ----------------------------------------------------
>
>                 Key: JBTM-117
>                 URL: http://jira.jboss.com/jira/browse/JBTM-117
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Should update to talk about interposition interceptor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:14:43 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Thu, 28 Sep 2006 12:14:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-117) release notes for JTS
 talk about context interceptor
In-Reply-To: <4031051.1155223512756.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30187869.1159460083630.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-117?page=all ]

Kevin Conner closed JBTM-117.
-----------------------------


> release notes for JTS talk about context interceptor
> ----------------------------------------------------
>
>                 Key: JBTM-117
>                 URL: http://jira.jboss.com/jira/browse/JBTM-117
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation, Documentation
>    Affects Versions: 4.2.1
>            Reporter: Mark Little
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>
> Should update to talk about interposition interceptor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:29:41 2006
From: jira-events at jboss.com (Andrew Rubinger (JIRA))
Date: Thu, 28 Sep 2006 12:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <155313.1159460981856.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12344231 ] 
            
Andrew Rubinger commented on EJBTHREE-402:
------------------------------------------

EJB3 RC9 Patch Installer for JBoss AS 4.0.4-GA does not update $JBOSS_HOME/client/jboss-ejb3.jar.

If you're running a standalone client, and this JAR is in your classpath, you will receive the deserialization errors above.  To fix, ensure your client is referencing the version of jboss-ejb3.jar found in $JBOSS_HOME/server/deploy/[instanceName]/ejb3.deployer.

S,
ALR

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:47:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 12:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-356) Session bean
	assertions
In-Reply-To: <26202711.1158784440217.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23878968.1159462061710.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-356?page=comments#action_12344234 ] 
            
Gavin King commented on JBSEAM-356:
-----------------------------------

Can also do it for method calls:

@NotNull public String doSomething(@NotNull parameter) { .... }

> Session bean assertions
> -----------------------
>
>                 Key: JBSEAM-356
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-356
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>
> For people who like more of a design-by-contract style, we could let you specify Hibernate Validator annotations on the session bean, and check them after @PostConstruct and before and after each business method.
> eg.
> @Stateful
> public class Foo {
>     @NotNull private Bar bar;
>     @Min(0) int count;
> }

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 12:47:41 2006
From: jira-events at jboss.com (Andrew Rubinger (JIRA))
Date: Thu, 28 Sep 2006 12:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <15580788.1159462061920.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12344235 ] 
            
Andrew Rubinger commented on EJBTHREE-402:
------------------------------------------

Correction, the patch installer does not update $JBOSS_HOME/client/jboss-ejb3-client.jar 

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:20:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-207) HTTP invoker
 configuration and testing
Message-ID: <2418240.1159464041847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-207?page=all ]

Ovidiu Feodorov updated JBMESSAGING-207:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> HTTP invoker configuration and testing
> --------------------------------------
>
>                 Key: JBMESSAGING-207
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-207
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Configuration and Management
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ron Sigal
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha2
>
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> Provide a HTTP invoker initial configuration and a working example.
> Add the example to docs/examples so it can be used as an integration test.
> Reviewed requirements:
> 1. The messaging client needs to connect to the server over HTTP
> 2. We need it implemented in such a way that there's no socket listening on the client, but the client can still receive messages asynchronously.
> 3. When the change is completed, all current Messaging functional tests, stress tests and smoke test must pass.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:26:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-516) Clustering
In-Reply-To: <13854429.1155575300086.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24056857.1159464401643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-516?page=all ]

Ovidiu Feodorov updated JBMESSAGING-516:
----------------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

Container tasks, needs to be completed by Beta.

> Clustering
> ----------
>
>                 Key: JBMESSAGING-516
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-516
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Beta1
>
>
> Implement clustering as described in:
> http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:35:47 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-4) Load balancing
Message-ID: <1754753.1159464947507.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-4?page=all ]

Ovidiu Feodorov updated JBMESSAGING-4:
--------------------------------------

    Assignee: Tim Fox

> Load balancing
> --------------
>
>                 Key: JBMESSAGING-4
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-4
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:35:47 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 13:35:47 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-4) Load balancing
Message-ID: <12742017.1159464947916.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-4?page=all ]

Ovidiu Feodorov closed JBMESSAGING-4.
-------------------------------------

    Resolution: Done

Distributed destinations are done.

> Load balancing
> --------------
>
>                 Key: JBMESSAGING-4
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-4
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: JMS Clustering
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 13:57:43 2006
From: jira-events at jboss.com (David DeGroff (JIRA))
Date: Thu, 28 Sep 2006 13:57:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-27) Manage the wiki pages
 for consistency and traversal
Message-ID: <2246409.1159466263651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-27?page=all ]

David DeGroff closed JBESB-27.
------------------------------

    Resolution: Done

> Manage the wiki pages for consistency and traversal
> ---------------------------------------------------
>
>                 Key: JBESB-27
>                 URL: http://jira.jboss.com/jira/browse/JBESB-27
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>            Reporter: Mark Little
>         Assigned To: David DeGroff
>            Priority: Minor
>             Fix For: 4.0
>
>
> We need to make sure that the JBossESB wiki pages are up-to-date with respect to what happens on the forums and that they all have a consistent look-and-feel.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:14:41 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Thu, 28 Sep 2006 14:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-368) STATELESS component
 injection rules are not intuitive/undocumented
Message-ID: <30807595.1159467281452.JavaMail.jira@cloud.prod.atl2.jboss.com>

STATELESS component injection rules are not intuitive/undocumented
------------------------------------------------------------------

                 Key: JBSEAM-368
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-368
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


This is probably a non-issue, so feel free to ignore.

It took me a while to figure out why this works:

@In(create=true)
MyStatelessComponent myComponent;

but this doesn't:
@In
MyStatelessComponent myComponent;

It was easy to figure out that it apparently is required, but from looking at the documentation this isn't clear. I also found it difficult to think about "creation of a component" when it is already there in the stateless EJB pool. I checked the code and there is some consistency in the internal logic, of course.

Users however might read the docs and say: "@In searches all contexts hierarchically, so it should find myComponent in STATELESS, because Seam logged that binding on startup." 

Also, attempts to remove the create="true" with 

@In(value = "myComponent", scope = ScopeType.STATELESS)
MyStatelessComponent myComponent;

resulted in JNDI lookup("myComponent"), which makes not much sense and returns null.

I suggest we add something to the documentation about lookup/injection of stateless components (I'm not sure if I'm 100% right about this, otherwise I would have added it).

Side note, I found the following additional debug logging lines in Component.java very helpful during development:

   private Object getInstanceToInject(In in, String name, Object bean, boolean enforceRequired)
   {
      Object result;
      if ( name.startsWith("#") )
      {
         log.debug("Searching for injection variable with value binding expression: " + name);
         FacesContext facesCtx = FacesContext.getCurrentInstance();
         Application application = facesCtx.getApplication();
         result = application.createValueBinding(name).getValue(facesCtx);
      }
      else if (in.scope()==ScopeType.UNSPECIFIED)
      {
         log.debug("Searching hierarchically for injection variable in all scopes: " + name);
         result = getInstance(name, in.create());
      }
      else
      {
         if ( in.create() )
         {
            throw new IllegalArgumentException(
                  "cannot combine create=true with explicit scope on @In: " +
                  getAttributeMessage(name)
               );
         }
         log.debug("Searching for injection variable in scope: " + name + ", scope: " + in.scope());
         result = in.scope().getContext().get(name);
      }

      if (result==null && enforceRequired && in.required())
      {
         throw new RequiredException(
               "In attribute requires value for component: " +
               getAttributeMessage(name)
            );
      }
      else
      {
         return result;
      }
   }


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:39:42 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Thu, 28 Sep 2006 14:39:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-155) loanbrokerRequestDir
 and
 loanbrokerEmailTemplatePath need to be dynamically configured with the
 loanbroker configure ant task
Message-ID: <25899341.1159468782668.JavaMail.jira@cloud.prod.atl2.jboss.com>

loanbrokerRequestDir and loanbrokerEmailTemplatePath need to be dynamically configured with the loanbroker configure ant task
-----------------------------------------------------------------------------------------------------------------------------

                 Key: JBESB-155
                 URL: http://jira.jboss.com/jira/browse/JBESB-155
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1, 4.0 Beta 1
         Environment: any
            Reporter: Kurt Stam
         Assigned To: Tom Fennelly


The following two parameters are still not part of the trailblazer config script.

    loanbrokerRequestDir="/cygwin/home/kstam/dev/loanbroker_MP1/TrailBlazer-rtfiles/BankInput"
    loanbrokerEmailTemplatePath="/cygwin/home/kstam/dev/loanbroker_MP1/template"

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:50:42 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 28 Sep 2006 14:50:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-956) "no selection"
 for Theme Leads to Null Pointer Exception
In-Reply-To: <24425396.1152887231411.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <175895.1159469442052.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-956?page=all ]

Roy Russo resolved JBPORTAL-956.
--------------------------------

    Fix Version/s: 2.6.Alpha1
                       (was: 2.4.1 Final)
       Resolution: Done
         Assignee: Roy Russo

now default to default theme in layout definition.

> "no selection" for Theme Leads to Null Pointer Exception
> --------------------------------------------------------
>
>                 Key: JBPORTAL-956
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-956
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.4 Final
>         Environment: Fedora Core 5
>            Reporter: Richard Mitchell
>         Assigned To: Roy Russo
>             Fix For: 2.6.Alpha1
>
>
> I was experimenting with theme selection in 2.4.0-CR1.  I tried each of the four defined ones which each worked great.  I then tried "no selection" to see how that behaved.  I received an HTTP 500 error with a Null Pointer Exception whenever I went to a page from that point forward.
> I hadn't really "customized" much yet so that, after suggested in the user forum, I blew away the database.  All is fine now.  I am avoiding that "no selection" entry though.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:53:42 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Thu, 28 Sep 2006 14:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-823) Access to
 Portlet Action Request in LayoutStragegy
Message-ID: <9519351.1159469622282.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-823?page=all ]

Roy Russo resolved JBPORTAL-823.
--------------------------------

    Fix Version/s: 2.4.1 Final
                   2.6.Alpha1
       Resolution: Won't Fix
         Assignee: Roy Russo

> Access to Portlet Action Request in LayoutStragegy
> --------------------------------------------------
>
>                 Key: JBPORTAL-823
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-823
>             Project: JBoss Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Portal Theme
>    Affects Versions: 2.2 Final
>         Environment: Any
>            Reporter: patrickdalla
>         Assigned To: Roy Russo
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>
> I want to maximize a portlet when the user clicks in the edit button.
> I've made this using the layoutStrategy to chage the WindowState if strategyContext.getTargetPortlet().getPortletMode() is equal Mode.EDIT.
> But, after the portlet is in edit mode, I cannot chage his WindowState.
> I would like a way to change the windowstate when the user clicks the edit button but after in edit mode he could minimize the portlet or change the window state.
> Maybe if I could access de ActionRequest in LayoutStrategy.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 14:56:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3454) Unable to set
 negative values for MBean attributes using Twiddle command
In-Reply-To: <19472192.1154493671368.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25392908.1159469801761.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3454?page=all ]

Sakthi Samabsivam resolved JBAS-3454.
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA
       Resolution: Done

Code is completed:Setcommand and SetAttrCommand is modified to accept valid attributes. 

> Unable to set  negative  values for MBean attributes using Twiddle command
> --------------------------------------------------------------------------
>
>                 Key: JBAS-3454
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3454
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
> For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
> Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
> Possible problem might be, GetOpt class used in the org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as
> an invalid option.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 15:15:41 2006
From: jira-events at jboss.com (Andrew Rubinger (JIRA))
Date: Thu, 28 Sep 2006 15:15:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-402) Remoting
 proxies are not declaring serialVersionUIDs
Message-ID: <20200500.1159470941844.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-402?page=comments#action_12344246 ] 
            
Andrew Rubinger commented on EJBTHREE-402:
------------------------------------------

Ignore above comments; wrong version patched and checked.

> Remoting proxies are not declaring serialVersionUIDs
> ----------------------------------------------------
>
>                 Key: EJBTHREE-402
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-402
>             Project: EJB 3.0
>          Issue Type: Bug
>    Affects Versions: EJB 3.0 RC3
>            Reporter: Scott M Stark
>            Priority: Critical
>             Fix For: EJB 3.0 RC10 - FD
>
>
> Same old lack of explicit serialVersionUIDs causing major incompatibilities across releases:
> java: org.jnp.interfaces.NamingContext at bd0108
> Looking up RemoteCalculator
> javax.naming.CommunicationException [Root exception is java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:707)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:572)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:351)
> 	at trail.client.RemoteCalculatorClient.main(RemoteCalculatorClient.java:38)
> Caused by: java.io.InvalidClassException: org.jboss.ejb3.stateless.StatelessRemoteProxy; local class incompatible: stream classdesc serialVersionUID = 2583299153931800023, local class serialVersionUID = 8144530673853515126
> 	at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:519)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1546)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
> 	at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:57)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:637)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 15:53:42 2006
From: jira-events at jboss.com (Travis Klotz (JIRA))
Date: Thu, 28 Sep 2006 15:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPM-759) Hibernate variable
 type matchers do not deal HibernateProxy objects.
Message-ID: <11128760.1159473222112.JavaMail.jira@cloud.prod.atl2.jboss.com>

Hibernate variable type matchers do not deal HibernateProxy objects.
--------------------------------------------------------------------

                 Key: JBPM-759
                 URL: http://jira.jboss.com/jira/browse/JBPM-759
             Project: JBoss jBPM
          Issue Type: Bug
          Components: Core Engine
    Affects Versions:  jBPM 3.1.2
            Reporter: Travis Klotz
         Assigned To: Tom Baeyens


The hibernate type matchers(HibernateLongIdMatcher, HibernateStringIdMatcher) do not match against persistant objects that are wrapped in hibernate generated proxies.  

For example, if I have a User class registered with hibernate, and I try to store a lazily instantiated User object as a context variable in jBPM, The class of the User instance is not User,  its something like  User$$EnhancedByCGLIB$$12345.  When the hibernate type matchers try to match against this class,  they do so by checking the hibernate session factory for any metadata about the argument.  But the session factory does not know anything about User$$EnhancedByCGLIB$$12345, only User, which results in a no match.

I solved this localy by extending the type matchers and explicitly checking the argument for the HibernateProxy interface.  If I found it, I ran the rest of the checks against the super class of the argument.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:14:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 16:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
Message-ID: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unable to set  Valid negative  values for MBean attributes using Twiddle 
-------------------------------------------------------------------------

                 Key: JBAS-3718
                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1
            Reporter: Sakthi Samabsivam
            Priority: Minor
             Fix For: JBossAS-4.0.5.GA


When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
 For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
 Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
 Possible problem might be, GetOpt class used in the 
 org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:14:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 16:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16882637.1159474481753.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Sakthi Samabsivam reassigned JBAS-3718:
---------------------------------------

    Assignee: Sakthi Samabsivam

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:23:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 16:23:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-561) Write two
 simple examples
 (distributed queue/topic) and include them in the set shipped with the
 release
Message-ID: <27083718.1159475022538.JavaMail.jira@cloud.prod.atl2.jboss.com>

Write two simple examples (distributed queue/topic) and include them in the set shipped with the release
--------------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-561
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-561
             Project: JBoss Messaging
          Issue Type: Feature Request
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:26:42 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Thu, 28 Sep 2006 16:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-369) @Create and
 @Begin(FlushModeType.MANUAL) execute in wrong order
Message-ID: <29538664.1159475202156.JavaMail.jira@cloud.prod.atl2.jboss.com>

@Create and @Begin(FlushModeType.MANUAL) execute in wrong order
---------------------------------------------------------------

                 Key: JBSEAM-369
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-369
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


This is CVS HEAD:

@Name("catalog")
@Stateful
public class CatalogBean implements Catalog {

    @In(value = "caveatEmptorEM", create = true)
    private EntityManager em;

    @Create
    @Begin(flushMode = FlushModeType.MANUAL)
    public void refreshRootCategories() {
    ...
}

The EntityManager is in FlushMode.AUTO because it is injected before the ConversationInterceptor runs and reads the @Begin annotation. 

So ManagedPersistenceContext.create() runs and sets the flush mode before the setFlushMode() method on the Conversation component is called.


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:29:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 16:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-562) Adjust the
 installation script to support a clustered installation
Message-ID: <2558336.1159475381657.JavaMail.jira@cloud.prod.atl2.jboss.com>

Adjust the installation script to support a clustered installation
------------------------------------------------------------------

                 Key: JBMESSAGING-562
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-562
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:29:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 16:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-563) Update the
 documentation with a Clustering Intro
Message-ID: <284336.1159475381808.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update the documentation with a Clustering Intro
------------------------------------------------

                 Key: JBMESSAGING-563
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-563
             Project: JBoss Messaging
          Issue Type: Task
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Critical
             Fix For: 1.2.0.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:32:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 28 Sep 2006 16:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3720) Change structure of
 ClusteredSSO data in tree cache to avoid lock issues
Message-ID: <23544654.1159475561894.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change structure of ClusteredSSO data in tree cache to avoid lock issues
------------------------------------------------------------------------

                 Key: JBAS-3720
                 URL: http://jira.jboss.com/jira/browse/JBAS-3720
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-5.0.0.CR1


For each SSO entry, their should be child node per server where the SSO has been used.  This is different from the current where all the session data for an SSO is in one node. The data map in each child node would hold the session ids of the sessions active on that server.

This kind of structure avoids most lock contention between different servers.

Can't do this in 4.0.x as it prevents interoperation with earlier releases.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 16:35:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Thu, 28 Sep 2006 16:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3721) Clustered SSO
 entries not properly cleaned up if a server crashes
Message-ID: <27529202.1159475741727.JavaMail.jira@cloud.prod.atl2.jboss.com>

Clustered SSO entries not properly cleaned up if a server crashes 
------------------------------------------------------------------

                 Key: JBAS-3721
                 URL: http://jira.jboss.com/jira/browse/JBAS-3721
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Clustering, Web (Tomcat) service
    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.5.GA
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: JBossAS-4.0.6.CR1


If a server crashes, the entries for its sessions in the clustered sso cache will never be removed, and thus the sso may never be removed.

TreeCacheSSOManager needs to listen for view changes and discard sessions associated with dead servers.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:32:41 2006
From: jira-events at jboss.com (Sakthi Samabsivam (JIRA))
Date: Thu, 28 Sep 2006 17:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17838870.1159479161540.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Sakthi Samabsivam closed JBAS-3718.
-----------------------------------

    Resolution: Duplicate Issue

It was created with with wrong type of patch, instead of a support patch.

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.4.CR2, JBossAS-4.0.3 SP1
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:50:42 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:50:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
Message-ID: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>

on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
--------------------------------------------------------------

                 Key: JBAS-3722
                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Naming
    Affects Versions: JBossAS-4.0.5.GA
         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
            Reporter: Prabhat Jha
         Assigned To: Scott M Stark


testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :

javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
	at javax.naming.InitialContext.lookup(InitialContext.java:347)
	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
	... 19 more
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
	... 20 more
Caused by: java.net.ConnectException: Connection refused: connect
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
	at java.net.Socket.connect(Socket.java:461)
	at java.net.Socket.connect(Socket.java:411)
	at java.net.Socket.<init>(Socket.java:310)
	at java.net.Socket.<init>(Socket.java:212)
	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:59:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
Message-ID: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>

on Windowns: org.jboss.test.jrmp.test fail with CNFE
----------------------------------------------------

                 Key: JBAS-3723
                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
            Reporter: Prabhat Jha


Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.

DynLoadingFromSARUnitTestCase
DynLoadingFromSARUnpackedUnitTestCase 
DynLoadingUnitTestCase 


javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
	at javax.naming.InitialContext.lookup(InitialContext.java:347)
	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:219)
	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
	... 18 more





-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:59:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21289590.1159480781829.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Prabhat Jha updated JBAS-3723:
------------------------------

          Component/s: Remoting
    Affects Version/s: JBossAS-4.0.5.GA

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 17:59:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Thu, 28 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9980784.1159480781991.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Prabhat Jha reassigned JBAS-3723:
---------------------------------

    Assignee: Scott M Stark

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:03:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 18:03:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1060) Empty
 preferences values are not retrieved properly
Message-ID: <10898953.1159481021650.JavaMail.jira@cloud.prod.atl2.jboss.com>

Empty preferences values are not retrieved properly
---------------------------------------------------

                 Key: JBPORTAL-1060
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1060
             Project: JBoss Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Portal Portlet
    Affects Versions: 2.4 Final, 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.4.1 Final, 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:32:41 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 28 Sep 2006 18:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21786345.1159482761693.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Ryan Campbell updated JBAS-3723:
--------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:32:41 2006
From: jira-events at jboss.com (Ryan Campbell (JIRA))
Date: Thu, 28 Sep 2006 18:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22504470.1159482761902.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3722?page=all ]

Ryan Campbell updated JBAS-3722:
--------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:50:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 18:50:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1060) Empty
 preferences values are not retrieved properly
In-Reply-To: <10898953.1159481021650.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5405081.1159483841691.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1060?page=all ]

Julien Viet resolved JBPORTAL-1060.
-----------------------------------

    Resolution: Done

> Empty preferences values are not retrieved properly
> ---------------------------------------------------
>
>                 Key: JBPORTAL-1060
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1060
>             Project: JBoss Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Portal Portlet
>    Affects Versions: 2.4 Final, 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>             Fix For: 2.4.1 Final, 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 18:56:41 2006
From: jira-events at jboss.com (Richard Achmatowicz (JIRA))
Date: Thu, 28 Sep 2006 18:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-554) Create an
 Admin
 abstraction that would allow running generic JMS tests regardless of
 provider implementation
In-Reply-To: <10709624.1159217701106.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28276671.1159484201465.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-554?page=comments#action_12344268 ] 
            
Richard Achmatowicz commented on JBMESSAGING-554:
-------------------------------------------------

I have had a look at the existing approach to incorporating generic (JMS provider neutral)  JMS tests into the AS testsuite. I outlined there the problems I could forsee in using the approach.  Please see the posting: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=91386

I would like to try to convert one substantial test case (one which involves a lot of interaction with the server via the interface provided by JBossTestCase, in addition to any adminsitartive functions) to see how the approach works in practice. 




> Create an Admin abstraction that would allow running generic JMS tests regardless of provider implementation
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-554
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-554
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Richard Achmatowicz
>             Fix For: 1.2.0.Beta1
>
>
> Since Messaging and JBossMQ use slightly different ways of deploying their administered objects (destinations and connection factories), we need to create an unified Admin interface that would allow to deploy these artifacts regardless of provider implementation, and then create plug-ins for Messaging and MQ. 
> Initial work in this direction has been done by Adrian, see http://www.jboss.org/index.html?module=bb&op=viewtopic&t=72570

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:26:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 19:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1061) Support
 localized description of portlet preference entries
Message-ID: <29515665.1159486001527.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support localized description of portlet preference entries
-----------------------------------------------------------

                 Key: JBPORTAL-1061
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1061
             Project: JBoss Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 2.6.Alpha1
            Reporter: Julien Viet
         Assigned To: Julien Viet
             Fix For: 2.6.Alpha1




-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:26:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 19:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBPORTAL-1061) Support
 localized description of portlet preference entries
In-Reply-To: <29515665.1159486001527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1467200.1159486001686.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1061?page=all ]

Julien Viet updated JBPORTAL-1061:
----------------------------------

    Priority: Minor  (was: Major)

> Support localized description of portlet preference entries
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1061
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1061
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:38:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 19:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
Message-ID: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>

Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
-----------------------------------------------------------------------------------------------------

                 Key: JBMESSAGING-564
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
             Project: JBoss Messaging
          Issue Type: Bug
          Components: JMS Facade
    Affects Versions: 1.0.1.CR5, 1.2.0.Alpha1
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
            Priority: Minor
             Fix For: 1.0.1.CR6, 1.2.0.Alpha1


Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.

Investigate.

In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 19:38:41 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Thu, 28 Sep 2006 19:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-154) Change
 configuration for FTP
 listeners/actions to avoid need to replicate FTP parameters
In-Reply-To: <4026448.1159447421501.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18526164.1159486721772.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-154?page=comments#action_12344271 ] 
            
Esteban Schifman commented on JBESB-154:
----------------------------------------

I have introduced a kludge to avoid replication of FTP parameters in two different places.  It's quite un-elegant:  the listener will include the parameters needed by the action class inside the message. These parameters do NOT belong in the message as they should be configuration values for the action class itself, but it is a way around having to replicate the values.

> Change configuration for FTP listeners/actions to avoid need to replicate FTP parameters
> ----------------------------------------------------------------------------------------
>
>                 Key: JBESB-154
>                 URL: http://jira.jboss.com/jira/browse/JBESB-154
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0
>            Reporter: Esteban Schifman
>         Assigned To: Esteban Schifman
>            Priority: Minor
>
> FTP server/username/password are needed both by the RemoteDirectoryPoller, and the FTP classes
> As it stands now, they need to be replicated in the xml configuration file for listeners and actions.  This is not appropriate and we should find ways to avoid this need.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:29:41 2006
From: jira-events at jboss.com (Julien Viet (JIRA))
Date: Thu, 28 Sep 2006 20:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1061) Support
 localized description of portlet preference entries
In-Reply-To: <29515665.1159486001527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25487229.1159489781586.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1061?page=all ]

Julien Viet resolved JBPORTAL-1061.
-----------------------------------

    Resolution: Done

> Support localized description of portlet preference entries
> -----------------------------------------------------------
>
>                 Key: JBPORTAL-1061
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1061
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.6.Alpha1
>            Reporter: Julien Viet
>         Assigned To: Julien Viet
>            Priority: Minor
>             Fix For: 2.6.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:35:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-275) Move Selector
 processing IN the Channel
Message-ID: <4134343.1159490142198.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-275?page=all ]

Ovidiu Feodorov updated JBMESSAGING-275:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> Move Selector processing IN the Channel
> ---------------------------------------
>
>                 Key: JBMESSAGING-275
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-275
>             Project: JBoss Messaging
>          Issue Type: Task
>          Components: Messaging Core
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha2
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> Currently, a consumer "arrests" a message that is being handled to it and doesn't match the Selector. That means it returns an active Delivery for it, but it doesn't forward the message to the client. This is because the consumer needs to be able to receiver further messages coming after the non-matching message, and that may potentially match the selector.
> This is a poor solution that doesn't scale. We may end up with lots of non-matching messages being "arrested" by a consumer, while they could just be simply returned to the channel and forwarded to other potential consumers.
> A possible (right) approach is to move selector processing in the Channel, so the message is not even handled to the non-accepting cosumer. Review this and refactor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:35:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-16) A
 PointToMultipoint should be able to do delivery on separate threads
Message-ID: <9473846.1159490142402.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-16?page=all ]

Ovidiu Feodorov updated JBMESSAGING-16:
---------------------------------------

    Fix Version/s: 1.2.0.Beta1
                       (was: 1.2.0.Alpha1)

> A PointToMultipoint should be able to do delivery on separate threads
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-16
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-16
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>          Components: Messaging Core
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Beta1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:35:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-517) Implement
 intelligent balancer
In-Reply-To: <8674188.1155575300202.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20299654.1159490142554.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-517?page=all ]

Ovidiu Feodorov closed JBMESSAGING-517.
---------------------------------------

    Resolution: Done

> Implement intelligent balancer
> ------------------------------
>
>                 Key: JBMESSAGING-517
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-517
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Implement intelligent balancer as described in
> http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-407) XARecovery
 integration of JBossMessaging with JBossTS
Message-ID: <5779613.1159490322339.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-407?page=all ]

Ovidiu Feodorov updated JBMESSAGING-407:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> XARecovery integration of JBossMessaging with JBossTS
> -----------------------------------------------------
>
>                 Key: JBMESSAGING-407
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-407
>             Project: JBoss Messaging
>          Issue Type: Patch
>          Components: Tests and Performance
>         Environment: JBoss 4.0.3SP1, JBossTs 4.2GA, JBOSS Messagig 1.0.1CR2
>            Reporter: Madhusudhan Konda
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha2
>
>         Attachments: artifacts.zip, jms-recovery-patch-all.txt, jms.zip, JMSProviderXAResourceRecovery.java, xa.zip, xarecovery-patch.txt, XATestStandaloneRecovery.java
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> To make JBossMessaging XAResource as recoverable using JBossTS RecoveryManager

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-518) Implement
 distributed destinations
In-Reply-To: <13023948.1155575300385.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17427252.1159490322616.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-518?page=all ]

Ovidiu Feodorov closed JBMESSAGING-518.
---------------------------------------

    Resolution: Done

> Implement distributed destinations
> ----------------------------------
>
>                 Key: JBMESSAGING-518
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-518
>             Project: JBoss Messaging
>          Issue Type: Sub-task
>            Reporter: Tim Fox
>         Assigned To: Tim Fox
>             Fix For: 1.2.0.Alpha1
>
>
> Implement distributed queue and topic as described in http://wiki.jboss.org/wiki/Wiki.jsp?page=NewClusteringDesign

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-289) Make service
 container configurable wrt datasource and persistence manager config
Message-ID: <11944163.1159490322789.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-289?page=all ]

Ovidiu Feodorov updated JBMESSAGING-289:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> Make service container configurable wrt datasource and persistence manager config
> ---------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-289
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-289
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha2
>
>
> Must be made configurable so test suite can be run against different databases with different pm configs

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-548)
 JBossConnection.finalizer()
 causes remote tests to occasionaly fail with "Cannot find generator for
 serverid:server.0"
In-Reply-To: <12006748.1158787861337.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6114019.1159490322924.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-548?page=all ]

Ovidiu Feodorov updated JBMESSAGING-548:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha2
                       (was: 1.2.0.Alpha1)

> JBossConnection.finalizer() causes remote tests to occasionaly fail with "Cannot find generator for serverid:server.0"
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-548
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-548
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.0.1.CR4
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Minor
>             Fix For: 1.2.0.Alpha2
>
>
> Apparently MessageIdGeneratorFactory gets inadvertently cleaned, or there are more check ins than check outs for a specific MessageIdGenerator instance.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:43 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 20:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-790) NPE on getNotifier
 after cache instantiation
Message-ID: <19812154.1159490323100.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE on getNotifier after cache instantiation
--------------------------------------------

                 Key: JBCACHE-790
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-790
             Project: JBoss Cache
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Ben Wang
         Assigned To: Manik Surtani
             Fix For: 2.0.0


Consider the following scenario:

cache = DefaultCacheFactory.createInstance(config, false); // not to start cache lifecycle
cache.getNotifier(); // return null becuase it is created in create() method call.

I think we need to move the notifier creation to the constructor.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 20:38:43 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Thu, 28 Sep 2006 20:38:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-444) Release
	1.2.0.Alpha1
In-Reply-To: <4902145.1153769531475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21444078.1159490323249.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-444?page=all ]

Ovidiu Feodorov updated JBMESSAGING-444:
----------------------------------------

    Priority: Blocker  (was: Major)

> Release 1.2.0.Alpha1
> --------------------
>
>                 Key: JBMESSAGING-444
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-444
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:14:41 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 28 Sep 2006 21:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-201) Release 1.1 beta 3
In-Reply-To: <4511003.1153758791655.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30719085.1159492481651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-201?page=all ]

Alejandro Guizar resolved BPEL-201.
-----------------------------------

    Resolution: Out of Date

Beta 3 will be skipped to focus on GA.

> Release 1.1 beta 3
> ------------------
>
>                 Key: BPEL-201
>                 URL: http://jira.jboss.com/jira/browse/BPEL-201
>             Project: JBoss jBPM BPEL
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Engine
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> The focus of this release is on fault handlers and compensation.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:17:41 2006
From: jira-events at jboss.com (Alejandro Guizar (JIRA))
Date: Thu, 28 Sep 2006 21:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (BPEL-212) Modularize package
 org.jbpm.bpel.def
In-Reply-To: <7572.1159228681195.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4591172.1159492661666.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/BPEL-212?page=all ]

Alejandro Guizar resolved BPEL-212.
-----------------------------------

    Resolution: Done

> Modularize package org.jbpm.bpel.def
> ------------------------------------
>
>                 Key: BPEL-212
>                 URL: http://jira.jboss.com/jira/browse/BPEL-212
>             Project: JBoss jBPM BPEL
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: jBPM BPEL 1.1 beta 2
>            Reporter: Alejandro Guizar
>         Assigned To: Alejandro Guizar
>             Fix For: jBPM BPEL 1.1
>
>
> The package org.jbpm.bpel.def concentrates all activity definitions and has become monolithic. The proposal is breaking it as follows:
> org.jbpm.bpel.graph.def: Core concepts, including BpelDefinition, Activity, CompositeActivity and LinkDefinition.
> org.jbpm.bpel.graph.basic: Basic activities
> org.jbpm.bpel.graph.struct: Structured activities
> org.jbpm.bpel.graph.scope: Scope activity plus fault, compensation, event and termination handlers
> For consistency, org.jbpm.bpel.exe becomes org.jbpm.bpel.graph.exe. Because the number of execution objects is small, there is no need to break this package.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:26:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-370) Default @Out scope
 to the component scope
Message-ID: <13701528.1159493201633.JavaMail.jira@cloud.prod.atl2.jboss.com>

Default @Out scope to the component scope
-----------------------------------------

                 Key: JBSEAM-370
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-370
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Currently @Out defaults to EVENT scope for simple values that are not Seam components. For consistence with @DataModel, we should change to defaulting to the scope of the component which outjects the value. This is probably a better default anyway.

Note that this is a breaking change, but best 'tis done now.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:26:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-370) Default @Out scope
 to the component scope
In-Reply-To: <13701528.1159493201633.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26029816.1159493201921.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-370?page=all ]

Gavin King closed JBSEAM-370.
-----------------------------

    Resolution: Done

> Default @Out scope to the component scope
> -----------------------------------------
>
>                 Key: JBSEAM-370
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-370
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> Currently @Out defaults to EVENT scope for simple values that are not Seam components. For consistence with @DataModel, we should change to defaulting to the scope of the component which outjects the value. This is probably a better default anyway.
> Note that this is a breaking change, but best 'tis done now.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:29:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-371) s:link does not
 propagate data model var
Message-ID: <14636107.1159493381980.JavaMail.jira@cloud.prod.atl2.jboss.com>

s:link does not propagate data model var
----------------------------------------

                 Key: JBSEAM-371
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-371
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: JSF
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


When using h:commandLink and h:commandButton, you can use the iterator variable in the method binding expression. s:link should be the same.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:29:42 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-371) s:link does not
 propagate data model var
In-Reply-To: <14636107.1159493381980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25125796.1159493382120.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-371?page=all ]

Gavin King updated JBSEAM-371:
------------------------------

    Description: When using h:commandLink and h:commandButton inside a h:dataTable, you can use the iterator variable in the method binding expression. s:link should be the same.  (was: When using h:commandLink and h:commandButton, you can use the iterator variable in the method binding expression. s:link should be the same.)

> s:link does not propagate data model var
> ----------------------------------------
>
>                 Key: JBSEAM-371
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-371
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> When using h:commandLink and h:commandButton inside a h:dataTable, you can use the iterator variable in the method binding expression. s:link should be the same.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:29:42 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-371) s:link does not
 propagate data model var
In-Reply-To: <14636107.1159493381980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10474901.1159493382233.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-371?page=all ]

Gavin King closed JBSEAM-371.
-----------------------------

    Resolution: Done

> s:link does not propagate data model var
> ----------------------------------------
>
>                 Key: JBSEAM-371
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-371
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> When using h:commandLink and h:commandButton inside a h:dataTable, you can use the iterator variable in the method binding expression. s:link should be the same.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:32:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-324) <s:link
 action="#{...}"/> does not work with clustering or bookmarking
In-Reply-To: <1013539.1154400311354.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30834671.1159493561568.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-324?page=comments#action_12344282 ] 
            
Gavin King commented on JBSEAM-324:
-----------------------------------

Ack, not so easy. There seems to be really no good way to implement this. Perhaps some solution using encryption?

> <s:link action="#{...}"/> does not work with clustering or bookmarking
> ----------------------------------------------------------------------
>
>                 Key: JBSEAM-324
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-324
>             Project: JBoss Seam
>          Issue Type: Bug
>          Components: JSF
>    Affects Versions: 1.0.1
>            Reporter: Gavin King
>         Assigned To: Gavin King
>            Priority: Critical
>             Fix For: 1.1
>
>
> We need to pass the id of the HtmlLink component, instead of the encoded method name.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 21:32:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Thu, 28 Sep 2006 21:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-316) The view attribute
 functionality of s:link tag extension
In-Reply-To: <29779016.1153601891526.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15500945.1159493561998.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-316?page=all ]

Gavin King updated JBSEAM-316:
------------------------------

    Fix Version/s:     (was: 1.1)

> The view attribute functionality of s:link tag extension
> --------------------------------------------------------
>
>                 Key: JBSEAM-316
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-316
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: JSF
>    Affects Versions: 1.0.1
>         Environment: N/A
>            Reporter: Slawomir Trybus
>            Priority: Minor
>
> I'd like to propose extending of the <s:link .../> tag functionality in the view attribute area by adding value-binding feature.
> example:
> <s:link view="#{...}" />
> There is inevitible to create another method returning outcome string with the action attribute in the current functionality of this tag. Such a solution would provide derived url without extra method execution.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 22:20:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 22:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBCACHE-791) PojoCache to
 revisit implementation for get/put Options
Message-ID: <18175183.1159496441631.JavaMail.jira@cloud.prod.atl2.jboss.com>

PojoCache to revisit implementation for get/put Options
-------------------------------------------------------

                 Key: JBCACHE-791
                 URL: http://jira.jboss.com/jira/browse/JBCACHE-791
             Project: JBoss Cache
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: PojoCache
            Reporter: Ben Wang
         Assigned To: Ben Wang
             Fix For: 2.0.0


During the initial implementation of PojoCache, we have to disable the Option API like supressLocking, etc in InternaHelper. We need to revisit them to make sure they are performant.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 22:47:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 22:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-680) TreeCache demo gui
 to update view instanteously
Message-ID: <8887952.1159498061847.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-680?page=all ]

Ben Wang updated JBCACHE-680:
-----------------------------

    Fix Version/s: 2.0.0
                       (was: 1.4.0)

> TreeCache demo gui to update view instanteously
> -----------------------------------------------
>
>                 Key: JBCACHE-680
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-680
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> Previously the demo gui window has the onModify view change disabled becuase the potential deadlock when there is a tx scope and the Swing GUI view update is coming in from a different thread context. I can't reproduce this on 1.4 release now but to safeguard it, on the GUI side, I have used the getData() api to bypass the locking anyway.
> Now, when I run the gui on PojoCache tutorial, it will have the field update automatically.

-- 
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

        


From jira-events at jboss.com  Thu Sep 28 22:47:41 2006
From: jira-events at jboss.com (Ben Wang (JIRA))
Date: Thu, 28 Sep 2006 22:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-680) TreeCache demo gui
 to update view instanteously
Message-ID: <21115871.1159498061950.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-680?page=all ]

Ben Wang updated JBCACHE-680:
-----------------------------

    Fix Version/s: 1.4.0.SP2

> TreeCache demo gui to update view instanteously
> -----------------------------------------------
>
>                 Key: JBCACHE-680
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-680
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Ben Wang
>         Assigned To: Ben Wang
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0.SP2
>
>
> Previously the demo gui window has the onModify view change disabled becuase the potential deadlock when there is a tx scope and the Swing GUI view update is coming in from a different thread context. I can't reproduce this on 1.4 release now but to safeguard it, on the GUI side, I have used the getData() api to bypass the locking anyway.
> Now, when I run the gui on PojoCache tutorial, it will have the field update automatically.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 01:27:42 2006
From: jira-events at jboss.com (Grant Quimby (JIRA))
Date: Fri, 29 Sep 2006 01:27:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3724)
 NotFoundInDispatcherException
 from InvokerLocator when accessing remote calls when on a non default port
Message-ID: <30204193.1159507662325.JavaMail.jira@cloud.prod.atl2.jboss.com>

NotFoundInDispatcherException from InvokerLocator when accessing remote calls when on a non default port
--------------------------------------------------------------------------------------------------------

                 Key: JBAS-3724
                 URL: http://jira.jboss.com/jira/browse/JBAS-3724
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Deployment services, EJB3, Remoting
    Affects Versions: JBossAS-4.0.4.GA
         Environment: One JBoss 4.0.4.GA install with two instances, one on the default ports and one on ports with an increase of 1000 on all port numbers. 
            Reporter: Grant Quimby
         Assigned To: Dimitris Andreadis
            Priority: Blocker


When trying to access a remote application that is running in a server instance that does not have the default InvokerLocator port (3873) the remote caller recieves a NotFoundInDispatcherException when trying to call a method in the EJB3 Stateless Session Bean as the EJB3 Session Bean's InvokerLocator is at port 4873 and not port 3873 where the Remote Proxy looks. 

Similar issue for Service Beans at http://www.jboss.com/index.html?module=bb&op=viewtopic&t=89537

This is okay presently but in approximately two weeks we need to be running four instances with Session beans in two of them, which is currently not possible in a production version.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 02:11:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 02:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
Message-ID: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>

Race Condition between Topic/Queue.getMessageCount and Deliver Thread
---------------------------------------------------------------------

                 Key: JBMESSAGING-565
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
             Project: JBoss Messaging
          Issue Type: Bug
    Affects Versions: 1.2.0.Alpha1
            Reporter: Clebert Suconic
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Alpha2


This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.

QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.

PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder

deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.

While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.

To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.

I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 02:14:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 02:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-565) Race
 Condition between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11408645.1159510481548.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic reassigned JBMESSAGING-565:
-------------------------------------------

    Assignee: Clebert Suconic  (was: Ovidiu Feodorov)

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha2
>
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 02:14:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 02:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30766159.1159510481679.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic updated JBMESSAGING-565:
----------------------------------------

    JBoss Forum Reference: http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975072#3975072

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha2
>
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:20:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <162341.1159514441476.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Dimitris Andreadis reopened JBAS-3718:
--------------------------------------

             

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: JBossAS-4.0.5.GA
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:23:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3718) Unable to set Valid
 negative values for MBean attributes using Twiddle
In-Reply-To: <29127754.1159474481567.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16768762.1159514621712.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3718?page=all ]

Dimitris Andreadis closed JBAS-3718.
------------------------------------

    Fix Version/s: No Release
                       (was: JBossAS-4.0.5.GA)
       Resolution: Done

I made a comment in the original case. The use of '--' shouldn't tell getopts to stop processing options? This needs to be invastigated.

> Unable to set  Valid negative  values for MBean attributes using Twiddle 
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3718
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3718
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2, JBossAS-4.0.4.GA
>            Reporter: Sakthi Samabsivam
>         Assigned To: Sakthi Samabsivam
>            Priority: Minor
>             Fix For: No Release
>
>
> When a customer tries to execute twiddle to set a negative value for one of the attributes, it throws the exception.
>  For example when I try to set a Scheduler MBean InitialRepitions value to -1, it fails.
>  Command: twiddle set "jboss:service=Scheduler" "InitialRepetitions" "-1".
>  Possible problem might be, GetOpt class used in the 
>  org.jboss.console.twiddle.SetCommand Class is not accepting the -ve values.It consider the -ve numbers as an invalid option.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:23:42 2006
From: jira-events at jboss.com (raehalme (JIRA))
Date: Fri, 29 Sep 2006 03:23:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3725) Specify DataSource
 settings at the application level (in the .EAR)
Message-ID: <18292068.1159514622075.JavaMail.jira@cloud.prod.atl2.jboss.com>

Specify DataSource settings at the application level (in the .EAR)
------------------------------------------------------------------

                 Key: JBAS-3725
                 URL: http://jira.jboss.com/jira/browse/JBAS-3725
             Project: JBoss Application Server
          Issue Type: Patch
      Security Level: Public (Everyone can see)
          Components: CMP service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: raehalme
         Assigned To: Alexey Loubyansky


At the moment you can specify application's DataSource settings either in the global JBoss configuration (standardjbosscmp-jdbc.xml) or in the EJB JAR (META-INF/jbosscmp-jdbc.xml). When developing EJB components that are re-used in many applications, it is frustrating to have to create a separate EJB JAR version for each application in order to be able to specify which DataSource to use for the EJB component. It would be much easier if the DataSource could be specified at the application level (in the EAR) because often all the application's EJB components use the same DataSource. In addition because the EJB JAR would no longer contain deployment specific settings, you could include the same EJB JAR file in all the application's EAR files.

I propose that this improvement is implemented by reading default settings also from the EAR's META-INF/jbosscmp-jdbc.xml. You could then specify a default configuration for each application and still override it inside the EJB JAR if necessary. I have implemented this functionality using the source code from version 4.0.4.GA. I will attach the necessary patches to this issue for your evaluation.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:26:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6547409.1159514801679.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3723?page=comments#action_12344312 ] 
            
Dimitris Andreadis commented on JBAS-3723:
------------------------------------------

Since when we are testing on windows? And is this the result of a full test run?

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Remoting
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:26:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 03:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3717) correct TCL should
 be used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9974285.1159514801824.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3717?page=all ]

Dimitris Andreadis updated JBAS-3717:
-------------------------------------

    Fix Version/s: JBossAS-4.0.5.GA

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:29:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 03:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-193) Enable
 configurable timeout on all calls of RpcServerCall.remoteInvoke(...)
Message-ID: <24252972.1159514981664.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-193?page=all ]

Ovidiu Feodorov closed JBMESSAGING-193.
---------------------------------------

    Resolution: Out of Date

Refers to old code.

> Enable configurable timeout on all calls of RpcServerCall.remoteInvoke(...)
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-193
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-193
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Messaging Core Distributed Support
>    Affects Versions: 1.0.0 alpha PR3
>            Reporter: Ovidiu Feodorov
>             Fix For: 1.2.0.Alpha1
>
>
> Client code currently lacks the possibility of administratively specify a timeout on RpcServerCall.remoteInvoke(...) calls.  This is case for PeerSupport, QueuePeer and maybe others. Add the possibility to specify this timeout in a configuration file.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:33:41 2006
From: jira-events at jboss.com (raehalme (JIRA))
Date: Fri, 29 Sep 2006 03:33:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3725) Specify DataSource
 settings at the application level (in the .EAR)
In-Reply-To: <18292068.1159514622075.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8308686.1159515221702.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3725?page=all ]

raehalme updated JBAS-3725:
---------------------------

    Attachment: JDBCEntityMetaData.java.patch
                JDBCXmlFileLoader.java.patch

JDBCXmlFileLoader.java: After reading standardjbosscmp-jdbc.xml the load method now reads META-INF/jbosscmp-jdbc.xml from the EAR, if available.

JDBCEntityMetaData.java: datasourceMappingName is now copied from the defaultValues. This change is necessary to support multiple levels of default values (the application's and the system's).

> Specify DataSource settings at the application level (in the .EAR)
> ------------------------------------------------------------------
>
>                 Key: JBAS-3725
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3725
>             Project: JBoss Application Server
>          Issue Type: Patch
>      Security Level: Public(Everyone can see) 
>          Components: CMP service
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: raehalme
>         Assigned To: Alexey Loubyansky
>         Attachments: JDBCEntityMetaData.java.patch, JDBCXmlFileLoader.java.patch
>
>
> At the moment you can specify application's DataSource settings either in the global JBoss configuration (standardjbosscmp-jdbc.xml) or in the EJB JAR (META-INF/jbosscmp-jdbc.xml). When developing EJB components that are re-used in many applications, it is frustrating to have to create a separate EJB JAR version for each application in order to be able to specify which DataSource to use for the EJB component. It would be much easier if the DataSource could be specified at the application level (in the EAR) because often all the application's EJB components use the same DataSource. In addition because the EJB JAR would no longer contain deployment specific settings, you could include the same EJB JAR file in all the application's EAR files.
> I propose that this improvement is implemented by reading default settings also from the EAR's META-INF/jbosscmp-jdbc.xml. You could then specify a default configuration for each application and still override it inside the EJB JAR if necessary. I have implemented this functionality using the source code from version 4.0.4.GA. I will attach the necessary patches to this issue for your evaluation.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 03:53:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 29 Sep 2006 03:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3717) correct TCL should
 be used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29100087.1159516421617.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3717?page=comments#action_12344315 ] 
            
Alexey Loubyansky commented on JBAS-3717:
-----------------------------------------

A testcase and fix committed to Branch_4_0.

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 06:32:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 06:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3726) Introduce basic
 twiddle tests in the testsuite
Message-ID: <24015765.1159525961573.JavaMail.jira@cloud.prod.atl2.jboss.com>

Introduce basic twiddle tests in the testsuite
----------------------------------------------

                 Key: JBAS-3726
                 URL: http://jira.jboss.com/jira/browse/JBAS-3726
             Project: JBoss Application Server
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Test Suite
            Reporter: Dimitris Andreadis
             Fix For: JBossAS-4.0.6.CR1


We currently have no automated tests for twidde.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 06:32:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 06:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3726) Introduce basic
 twiddle testing in the testsuite
In-Reply-To: <24015765.1159525961573.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29879945.1159525961692.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3726?page=all ]

Dimitris Andreadis updated JBAS-3726:
-------------------------------------

    Summary: Introduce basic twiddle testing in the testsuite  (was: Introduce basic twiddle tests in the testsuite)

> Introduce basic twiddle testing in the testsuite
> ------------------------------------------------
>
>                 Key: JBAS-3726
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3726
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>             Fix For: JBossAS-4.0.6.CR1
>
>
> We currently have no automated tests for twidde.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:11:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:11:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18368366.1159528302039.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis closed JBAS-3723.
------------------------------------

    Resolution: Done

They work for me using a special target 'tests-client-unit'

X:\cvs\jboss-public\jboss-4.0\testsuite>build tests-client-unit
Calling ..\tools\bin\ant.bat tests-client-unit
Buildfile: build.xml

tests-client-unit:
    [junit] Running org.jboss.test.jrmp.test.DynLoadingFromSARUnitTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.451 sec
    [junit] Running org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCa
se
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.995 sec
    [junit] Running org.jboss.test.jrmp.test.DynLoadingUnitTestCase
    [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 17.304 sec

BUILD SUCCESSFUL
Total time: 52 seconds

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:11:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:11:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9029404.1159528302242.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis reopened JBAS-3723:
--------------------------------------

      Assignee: Dimitris Andreadis  (was: Scott M Stark)
             

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: No Release
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:11:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:11:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25792394.1159528302463.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis updated JBAS-3723:
-------------------------------------

          Component/s: Test Suite
                           (was: Remoting)
        Fix Version/s: No Release
                           (was: JBossAS-4.0.5.GA)
    Affects Version/s:     (was: JBossAS-4.0.5.GA)

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>             Fix For: No Release
>
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:14:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3723) on Windowns:
 org.jboss.test.jrmp.test fail with CNFE
In-Reply-To: <28019925.1159480781719.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21378927.1159528481619.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3723?page=all ]

Dimitris Andreadis closed JBAS-3723.
------------------------------------

    Fix Version/s:     (was: No Release)
       Resolution: Rejected

As a note, when you open issues don't open them again the version to be released (e.g. 4.0.5.GA), since this version is not released yet!

Just leave the affects version empty.

> on Windowns: org.jboss.test.jrmp.test fail with CNFE
> ----------------------------------------------------
>
>                 Key: JBAS-3723
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3723
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>         Environment: Sun jdk1.4, windows 2003 (dev28 in qa lab)
>            Reporter: Prabhat Jha
>         Assigned To: Dimitris Andreadis
>
> Under the package org.jboss.test.jrmp.test,  follwoing test cases fail with ClassNotFoundException.
> DynLoadingFromSARUnitTestCase
> DynLoadingFromSARUnpackedUnitTestCase 
> DynLoadingUnitTestCase 
> javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.jrmp.test.DynLoadingFromSARUnpackedUnitTestCase.testAccess(DynLoadingFromSARUnpackedUnitTestCase.java:55)
> Caused by: java.lang.ClassNotFoundException: org.jboss.test.jrmp.ejb.AString
> 	at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
> 	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
> 	at java.lang.Class.forName0(Native Method)
> 	at java.lang.Class.forName(Class.java:219)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:430)
> 	at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
> 	at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
> 	at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
> 	at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
> 	at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
> 	at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
> 	at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
> 	at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
> 	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
> 	at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
> 	at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:72)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:652)
> 	... 18 more

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:23:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 07:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-138) Make TS changes
 available for AS 4.0.4 patch process
Message-ID: <29572011.1159529021616.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make TS changes available for AS 4.0.4 patch process
----------------------------------------------------

                 Key: JBTM-138
                 URL: http://jira.jboss.com/jira/browse/JBTM-138
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kevin Conner
         Assigned To: Kevin Conner


We need to provide our patches as part of the cumulative patch process for AS 4.0.4.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:26:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 07:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
Message-ID: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>

The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBTM-139
                 URL: http://jira.jboss.com/jira/browse/JBTM-139
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTA Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:26:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 07:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-140) The JTS
 UserTransaction raises the
 wrong exception if the transaction has been terminated through the
 transaction reaper as a consequence of a timeout.
Message-ID: <15892972.1159529201835.JavaMail.jira@cloud.prod.atl2.jboss.com>

The JTS UserTransaction raises the wrong exception if the transaction has been terminated through the transaction reaper as a consequence of a timeout.
-------------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: JBTM-140
                 URL: http://jira.jboss.com/jira/browse/JBTM-140
             Project: JBoss Transaction Manager
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: JTS Implementation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Kevin Conner
             Fix For: 4.2.2




-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:29:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3715) 1 failing test in
 org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
In-Reply-To: <12635616.1159439561787.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26287616.1159529381706.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3715?page=all ]

Dimitris Andreadis closed JBAS-3715.
------------------------------------

    Resolution: Done

I think it's passing now.

> 1 failing test in org.jboss.test.security.test.SRPLoginModuleUnitTestCase (rockit)
> ----------------------------------------------------------------------------------
>
>                 Key: JBAS-3715
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3715
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: Security, Test Suite
>         Environment: Java Version 1.4.2_11 
> Java Vendor BEA Systems, Inc. 
> Java VM Name BEA JRockit(R) 
> Java VM Version R26.4.0-63-63688-1.4.2_11-20060626-2259-linux-ia32 
> Java VM Info  
> OS Name Linux 
> OS Version 2.6.9-42.0.2.ELsmp 
> OS Arch i386 
>            Reporter: Dimitris Andreadis
>         Assigned To: Rajesh Rajasekaran
>             Fix For: JBossAS-4.0.5.GA
>
>
> testSRPLoginWithAuxChallenge Failure
> Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> junit.framework.AssertionFailedError: Unable to complete login: Failed to complete SRP login, msg=Failed to encrypt aux challenge
> 	at org.jboss.test.security.test.SRPLoginModuleUnitTestCase.testSRPLoginWithAuxChallenge(SRPLoginModuleUnitTestCase.java:142)
> 	at jrockit.reflect.VirtualNativeMethodInvoker.invoke(Ljava.lang.Object;[Ljava.lang.Object;)Ljava.lang.Object;(Unknown Source)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> The same test passes with Sun Jdk1.4 but I believe this is due to 
> jrockit-R26.4.0-jdk1.4.2_11\jre\lib\security
>    local_policy.jar
>    US_export_policy.jar
> Not updated to include unlimited crypto ability?

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 07:53:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Fri, 29 Sep 2006 07:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13550007.1159530821813.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344321 ] 
            
Dimitris Andreadis commented on JBAS-3722:
------------------------------------------

It could be we are not running the tests properly. Are there any environment settings needed like 

MYTESTIP_1
MYTESTIP_2

?

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 09:17:41 2006
From: jira-events at jboss.com (Tim Fox (JIRA))
Date: Fri, 29 Sep 2006 09:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-564)
 Session.unsubscribe() leaves
 an active associated consumer (durable subscriber) in an undefined state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30076363.1159535861803.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Tim Fox closed JBMESSAGING-564.
-------------------------------

    Resolution: Rejected
      Assignee: Tim Fox  (was: Ovidiu Feodorov)

This test is not valid.

It is illegal (see JMS1.1 spec 6.11) to unsubscribe if the subscription has active consumers.

We weren't checking this in the code before.

I have now added such a check, and a test.

This test should be removed and this bug closed.

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.CR6, 1.2.0.Alpha1
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-140) The JTS
 UserTransaction raises
 the wrong exception if the transaction has been terminated through the
 transaction reaper as a consequence of a timeout.
In-Reply-To: <15892972.1159529201835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33469868.1159538561886.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-140?page=all ]

Kevin Conner resolved JBTM-140.
-------------------------------

    Resolution: Rejected

> The JTS UserTransaction raises the wrong exception if the transaction has been terminated through the transaction reaper as a consequence of a timeout.
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-140
>                 URL: http://jira.jboss.com/jira/browse/JBTM-140
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:02:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-140) The JTS
 UserTransaction raises
 the wrong exception if the transaction has been terminated through the
 transaction reaper as a consequence of a timeout.
In-Reply-To: <15892972.1159529201835.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26897621.1159538561732.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-140?page=comments#action_12344326 ] 
            
Kevin Conner commented on JBTM-140:
-----------------------------------

This report is incorrect, the JTS does raise an InvalidStateException when the transaction has been terminated by the transaction reaper

> The JTS UserTransaction raises the wrong exception if the transaction has been terminated through the transaction reaper as a consequence of a timeout.
> -------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-140
>                 URL: http://jira.jboss.com/jira/browse/JBTM-140
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTS Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:11:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
In-Reply-To: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <624575.1159539101562.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBTM-139?page=comments#action_12344327 ] 
            
Kevin Conner commented on JBTM-139:
-----------------------------------

Fixed in revision 6468

> The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-139
>                 URL: http://jira.jboss.com/jira/browse/JBTM-139
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:11:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
In-Reply-To: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21621896.1159539101733.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-139?page=all ]

Kevin Conner resolved JBTM-139.
-------------------------------

    Resolution: Done

> The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-139
>                 URL: http://jira.jboss.com/jira/browse/JBTM-139
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:11:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBTM-139) The JTA
 UserTransaction does not
 disassociate the transaction from the current thread if it has been
 terminated through the transaction reaper as a consequence of a timeout.
In-Reply-To: <15771212.1159529201599.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10630264.1159539101852.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBTM-139?page=all ]

Kevin Conner closed JBTM-139.
-----------------------------


> The JTA UserTransaction does not disassociate the transaction from the current thread if it has been terminated through the transaction reaper as a consequence of a timeout.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBTM-139
>                 URL: http://jira.jboss.com/jira/browse/JBTM-139
>             Project: JBoss Transaction Manager
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JTA Implementation
>    Affects Versions: 4.2.1
>            Reporter: Kevin Conner
>         Assigned To: Kevin Conner
>             Fix For: 4.2.2
>
>


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:14:41 2006
From: jira-events at jboss.com (Kevin Conner (JIRA))
Date: Fri, 29 Sep 2006 10:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBTM-141) The fix for JBTM-139
 requires updates to the documentation.
Message-ID: <10248828.1159539281807.JavaMail.jira@cloud.prod.atl2.jboss.com>

The fix for JBTM-139 requires updates to the documentation.
-----------------------------------------------------------

                 Key: JBTM-141
                 URL: http://jira.jboss.com/jira/browse/JBTM-141
             Project: JBoss Transaction Manager
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
    Affects Versions: 4.2.1
            Reporter: Kevin Conner
         Assigned To: Mark Little
             Fix For: 4.2.2


Documentation update for JBTM-139


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:35:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 10:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
Message-ID: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>

NPE on context classloader changing in EJB container when caller doesn't have a context classloader
---------------------------------------------------------------------------------------------------

                 Key: JBAS-3727
                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
             Project: JBoss Application Server
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


The following code in org.jboss.ejb.Container
doesn't work if the caller doesn't have a context classloader,
e.g. it is using the bootstrap classloader as its classloader on the Sun JDK

      ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
      long start = System.currentTimeMillis();
      Method m = null;

      boolean setCl = false;
      Object type = null;
      String contextID = getJaccContextID();
      try
      {
         if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
         {
            setCl = true;
            SecurityActions.setContextClassLoader(this.classLoader);
         }

The classloaders should be reversed, since the ejb classloader can never be null.

Is there a reason for this optimization? I'd imagine the comparison of classloaders
is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:35:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 10:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3728) Check ClassLoader
	comparisons
Message-ID: <3800956.1159540541820.JavaMail.jira@cloud.prod.atl2.jboss.com>

Check ClassLoader comparisons
-----------------------------

                 Key: JBAS-3728
                 URL: http://jira.jboss.com/jira/browse/JBAS-3728
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.CR1
            Reporter: Adrian Brock
         Assigned To: Scott M Stark


The codebase needs checking for other classloader comparisons similar to that found
on the parent issue for the EJBContainer.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 10:50:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 29 Sep 2006 10:50:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBAS-3701)
 SystemPropertiesService does not
 properly generate server path on windows
In-Reply-To: <32333943.1159287401584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23397552.1159541441632.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3701?page=all ]

Anil Saldhana resolved JBAS-3701.
---------------------------------

    Resolution: Rejected

As per Adrian's suggestion, need to replace "/" with "${/}" for files/directories

 <!--  system properties -->
  <mbean code="org.jboss.varia.property.SystemPropertiesService"
    name="jboss:type=Service,name=SystemProperties">
    <attribute name="Properties" replace="false"> 
         log.file.location=${jboss.server.home.dir}${/}log 
         javax.net.ssl.keyStore=${jboss.server.home.dir}${/}conf${/}keystores${/}clientcert.jks 
    </attribute>
  </mbean>


This works.

> SystemPropertiesService does not properly generate server path on windows
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3701
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3701
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
>   <mbean code="org.jboss.varia.property.SystemPropertiesService"
>     name="jboss:type=Service,name=SystemProperties">
>     <attribute name="Properties" replace="false"> 
>          log.file.location=${jboss.server.home.dir}/log 
>     </attribute>
>   </mbean>
> The jboss.server.home.dir is not string replaced properly on windows.
> I suspect it to be related to the Property class in the Jboss common module.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:29:41 2006
From: jira-events at jboss.com (Darren Hartford (JIRA))
Date: Fri, 29 Sep 2006 11:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBCOMMON-6) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10316736.1159543781539.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBCOMMON-6?page=comments#action_12344332 ] 
            
Darren Hartford commented on JBCOMMON-6:
----------------------------------------

Adding support for the Eclipse 'bundleresource' URL would also be a huge benefit.


> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: JBCOMMON-6
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-6
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: core
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>            Priority: Critical
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:32:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 11:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8936795.1159543961643.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic updated JBMESSAGING-565:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.2.0.Alpha2)

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:35:41 2006
From: jira-events at jboss.com (Christian Bauer (JIRA))
Date: Fri, 29 Sep 2006 11:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-372) s:link doesn't get
 parent conversation Id after exit of nested conversation
Message-ID: <32073994.1159544141645.JavaMail.jira@cloud.prod.atl2.jboss.com>

s:link doesn't get parent conversation Id after exit of nested conversation
---------------------------------------------------------------------------

                 Key: JBSEAM-372
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-372
             Project: JBoss Seam
          Issue Type: Bug
            Reporter: Christian Bauer
            Priority: Minor


Consider this sequence:

- Conversation A -> s:link = startB(value, conversationId=A)
- Nested B ->  h:commandButton = Conversation.instance().endAndRedirect(conversationId=B);
- Conversation A -> s:link = startB(value, conversationId=null)
- crash

Basically, it looks like s:link doesn't append a conversation id if the conversation is marked as being discarded after RENDER RESPONSE. This is the case in the RENDER_RESPONSE after the redirect out of Nested B, the conversation B will be discarded. So s:link renders  without a conversation identifier. It should use the parent conversations identifier.


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:38:41 2006
From: jira-events at jboss.com (Clebert Suconic (JIRA))
Date: Fri, 29 Sep 2006 11:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-565) Race Condition
 between Topic/Queue.getMessageCount and Deliver Thread
In-Reply-To: <10770133.1159510301715.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12771899.1159544321729.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-565?page=all ]

Clebert Suconic closed JBMESSAGING-565.
---------------------------------------

    Resolution: Done

> Race Condition between Topic/Queue.getMessageCount and Deliver Thread
> ---------------------------------------------------------------------
>
>                 Key: JBMESSAGING-565
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-565
>             Project: JBoss Messaging
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Alpha1
>            Reporter: Clebert Suconic
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>          Time Spent: 1 day, 1 hour
>  Remaining Estimate: 0 minutes
>
> This is not necessarily a bug. It' s more a task, but I will assume it as a bug at this point.
> QueueManagementTest::testMessageCountOverFullSize has a race condition between getMessageCount and Deliver Thread.
> PagingChannelSupport::messageCount is an arithmethic expressions of messageRefs.size() + deliveries.size() + nextPagingOrder -  firstPagingOrder
> deliveries.size is being controlled by Delivery Thread, determined by DeliveryRunnable that runs as-synchronously on Destination.
> While getMessageCount might diverge momentarily it will eventually be fixed as soon as DeliveryRunnable has the appropriate time to send the result to the collection deliveries.
> To fix this we would need to synchronize delivery and messageCount somehow, probably adding global lock, what we don' t want to add I assume. So, if this is correct the test has to be fixed somehow.
> I have changed the test in such way it will make easier to identify the racing condition. Use tracing in your tests and you will see a retry routine that will eventually pass. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:41:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 11:41:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCOMMON-6) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31414866.1159544501865.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCOMMON-6?page=all ]

Adrian Brock updated JBCOMMON-6:
--------------------------------

     Original Estimate:     (was: 4 hours)
    Remaining Estimate:     (was: 4 hours)
              Priority: Major  (was: Critical)

"FOR COMMITTERS USE ONLY" means exactly that.

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: JBCOMMON-6
>                 URL: http://jira.jboss.com/jira/browse/JBCOMMON-6
>             Project: JBoss Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:41:42 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 11:41:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Moved: (EJBTHREE-719) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29775946.1159544502079.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/EJBTHREE-719?page=all ]

Adrian Brock moved JBCOMMON-6 to EJBTHREE-719:
----------------------------------------------

        Project: EJB 3.0  (was: JBoss Common)
            Key: EJBTHREE-719  (was: JBCOMMON-6)
    Component/s:     (was: core)

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: EJBTHREE-719
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-719
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:44:41 2006
From: jira-events at jboss.com (Brian Stansberry (JIRA))
Date: Fri, 29 Sep 2006 11:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27290804.1159544681832.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344335 ] 
            
Brian Stansberry commented on JBAS-3722:
----------------------------------------

What IP was the server bound to?  Has to be 10.16.56.139.  That comes from the "node0=xxx" line in testsuite/local.properties.  The 10.16.56.139 in the posted stack trace comes from system property jbosstest.server.host, which by default also comes from "node0=xxx"  in local.properties.  Only way  I could see those being out of sync is if jbosstest.server.host were being overridden in some way.

The stack trace above doesn't show much, as what's being reported is the expected failure of connecting to the naming server via java.naming.provider.url.  The real test failure is why automatic discovery didn't find the server when the above exception was caught. If you could attach the junit report for this test from testsuite/output/reports that may provide more info.

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:44:41 2006
From: jira-events at jboss.com (Adrian Brock (JIRA))
Date: Fri, 29 Sep 2006 11:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (EJBTHREE-719) Archive Browser
 does not support jar:file: url protocol
In-Reply-To: <6775560.1157574158198.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19223505.1159544681997.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/EJBTHREE-719?page=comments#action_12344336 ] 
            
Adrian Brock commented on EJBTHREE-719:
---------------------------------------

Moved the EJB3 project since I don't see what this archive browsing offers over its
more feature complete precursor org.jboss.net.URLLister[Factory]?

This should in any case be replaced with the VFS.

> Archive Browser does not support jar:file: url protocol
> -------------------------------------------------------
>
>                 Key: EJBTHREE-719
>                 URL: http://jira.jboss.com/jira/browse/EJBTHREE-719
>             Project: EJB 3.0
>          Issue Type: Bug
>         Environment: jdk 1.5.8
> jboss 4.0.4ga
> hibernate 3.2cr2
> hibernate entity manager 3.2.0.CR1
> Using ejb3/entity manager annotations
>            Reporter: Chris Mercer
>         Assigned To: Dimitris Andreadis
>
> We have a seperate jar file that contains all of our model/entity objects.  This jar gets put in the WEB-INF/lib directory, since we are only using wars and not ears.  Using the hibernate auto-discovery feature causes an exception to occur. In this configuration.
> Caused by: java.lang.RuntimeException: NOT IMPLEMENTED
> 	at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:42)
> 	at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:541)
> 	... 148 more
> org.jboss.util.file.ArchiveBrowser.getBrowser(URL url, Filter filter) only supports URLS that have a protocol of "file".  However, jars have a protocol of "jar:file:" and therefore it will throw a RuntimeException saying "NOT IMPLEMENTED" (at least according to my debugger).  There is already a JarArchiveBrowser class, the ArchiveBrowser just needs to recognize the protocol and handle it.  
> This also affects Hibernate entity manager, since it gets included in the jboss-archive-browsing.jar in order to handle the auto-discovery of mapped entities feature.  
> I've marked this as critical, since it effects entity manager features (though its only advanced hibernate only functionality)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:59:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 29 Sep 2006 11:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3717) correct TCL should
 be used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1133983.1159545581644.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3717?page=all ]

Alexey Loubyansky updated JBAS-3717:
------------------------------------

    Affects Version/s: JBossAS-3.2.8.SP1

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-3.2.8.SP2, JBossAS-4.0.5.GA
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 11:59:41 2006
From: jira-events at jboss.com (Alexey Loubyansky (JIRA))
Date: Fri, 29 Sep 2006 11:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3717) correct TCL should be
 used before starting entity PMs
In-Reply-To: <21758025.1159457921622.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19435653.1159545581859.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3717?page=all ]

Alexey Loubyansky closed JBAS-3717.
-----------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2
       Resolution: Done

Fixed.

> correct TCL should be used before starting entity PMs
> -----------------------------------------------------
>
>                 Key: JBAS-3717
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3717
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Alexey Loubyansky
>         Assigned To: Alexey Loubyansky
>             Fix For: JBossAS-4.0.5.GA, JBossAS-3.2.8.SP2
>
>
> In EjbModule before starting persistence managers for entity beans, correct thread class loader should be set. Like so
>    protected void startService() throws Exception
>    {
>       // before EntityContainer returns from the startService, its PM should be usable
>       ListIterator iter = containerOrdering.listIterator();
>       while( iter.hasNext() )
>       {
>          Container con = (Container) iter.next();
>          if(con.getBeanMetaData().isEntity())
>          {
>             ClassLoader oldCl = SecurityActions.getContextClassLoader();
>             SecurityActions.setContextClassLoader(con.getClassLoader());
>             try
>             {
>                ((EntityContainer)con).getPersistenceManager().start();
>             }
>             finally
>             {
>                // Reset classloader
>                SecurityActions.setContextClassLoader(oldCl);
>             }
>          }
>       }
> ...

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:02:41 2006
From: jira-events at jboss.com (Anil Saldhana (JIRA))
Date: Fri, 29 Sep 2006 12:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBAS-3701)
 SystemPropertiesService does not
 properly generate server path on windows
In-Reply-To: <32333943.1159287401584.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33190898.1159545761725.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3701?page=all ]

Anil Saldhana reopened JBAS-3701:
---------------------------------

             
The real issue is that the string replaced "jboss.server.home.dir" (eg: c:\something\something) goes through the call [string.getBytes("iso-8888-xxx")]  is stripped off the slashes and the end result is:

Csomethingsomething/log


> SystemPropertiesService does not properly generate server path on windows
> -------------------------------------------------------------------------
>
>                 Key: JBAS-3701
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3701
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.4.GA
>            Reporter: Anil Saldhana
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.6.CR1
>
>
>   <mbean code="org.jboss.varia.property.SystemPropertiesService"
>     name="jboss:type=Service,name=SystemProperties">
>     <attribute name="Properties" replace="false"> 
>          log.file.location=${jboss.server.home.dir}/log 
>     </attribute>
>   </mbean>
> The jboss.server.home.dir is not string replaced properly on windows.
> I suspect it to be related to the Property class in the Jboss common module.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:32:41 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Fri, 29 Sep 2006 12:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-744) Expand
 CacheLoader API to support streaming state transfer
In-Reply-To: <2386926.1156183900538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1738929.1159547561681.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-744?page=all ]

Vladimir Blagojevic resolved JBCACHE-744.
-----------------------------------------

    Resolution: Done

Resolved by introducing described methods in CacheLoader API. Default implementations of these methods have been moved to AbstractCacheLoader thus liberating concrete Cacheloader implementations from the details of partial and complete state transfer between cacheloaders. By resolving this issue cacheloader compatibility is also achieved. For example, cache node A can have FileCacheLoader and node B can have JDBCCacheLoader which are able to transfer state between them. Both streaming and byte based transfer are supported transparently from cacheloaders.



> Expand CacheLoader API to support streaming state transfer
> ----------------------------------------------------------
>
>                 Key: JBCACHE-744
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-744
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.4.0, 1.3.0, 1.2
>            Reporter: Vladimir Blagojevic
>         Assigned To: Vladimir Blagojevic
>             Fix For: 2.0.0
>
>
> CacheLoader API prior to 2.0 does not support streaming state transfer feature implemented in Jgroups 2.4. In order to transfer application state to a receiving cache node we currently have to load entire state into memory and send it to a receiving cache node. Major limitation of this approach is that the state transfer that is very large (>total memory allocated by JVM) would result in OutOfMemoryException. 
> For example, if a cacheloader is pointing to a huge DOM tree, whose aggregate size is 2GB (and which has partly been passivated to disk), then the state provider cacheloader node can simply iterate over the DOM tree (activating the parts which have been passivated out to disk), and write it to the OutputStream as it traverses the tree. The receiving cacheloader will simply read from the InputStream and reconstruct the tree on its side, possibly again passivating parts to disk. Rather than having to provide a 2GB byte[] buffer (besides the state, so the needed memory is ca 4GB temporarily), streaming state transfer transfers the state in chunks of N bytes (user configurable).
> In order to accomodate this feature CacheLoader API will be expanded to include the following methods:
> void storeEntireState(InputStream s);
> void storeState(Fqn subtree,InputStream s); 
> void loadEntireState(OutputStream s);
> void loadState(Fqn subtree,OutputStream s);

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:35:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Fri, 29 Sep 2006 12:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28781081.1159547741563.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344341 ] 
            
Prabhat Jha commented on JBAS-3722:
-----------------------------------

I have just started a fresh test run on windows. I will attach the junit report once it's done which will be after 4 hours.

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 12:44:41 2006
From: jira-events at jboss.com (Vladimir Blagojevic (JIRA))
Date: Fri, 29 Sep 2006 12:44:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-332) Support concurrent
	flushing
Message-ID: <25140947.1159548281781.JavaMail.jira@cloud.prod.atl2.jboss.com>

Support concurrent flushing
---------------------------

                 Key: JGRP-332
                 URL: http://jira.jboss.com/jira/browse/JGRP-332
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.4
            Reporter: Vladimir Blagojevic
         Assigned To: Vladimir Blagojevic
             Fix For: 2.5


JGroups 2.4 introduces FLUSH protocol that enables stop-the-world model for JGroups nodes. However, FLUSH protocol currently does not support coordination between nodes when it comes to concurrent requests for flush. For example, in JGroups 2.4 if more than one MuxChannel sitting on top of JChannel requests flush the behaviour is nondeterministic. Also, we should investigate how to combine concurrent flush requests coming from state transfer protocol with flush requests coming from GMS protocol. 

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 13:14:41 2006
From: jira-events at jboss.com (Kurt Stam (JIRA))
Date: Fri, 29 Sep 2006 13:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-156) consistent packaging
Message-ID: <9315890.1159550081789.JavaMail.jira@cloud.prod.atl2.jboss.com>

consistent packaging
--------------------

                 Key: JBESB-156
                 URL: http://jira.jboss.com/jira/browse/JBESB-156
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Kurt Stam
         Assigned To: Mark Little


Can we do some more refactoring of package names?

For example I'd like to see everything in

'product/core/common' directory to be rooted in the org.jboss.soa.esb.common.* package.
'product/core/services' directory to be rooted in the org.jboss.soa.esb.services.* package.

Somehow it's all mixed up right now and I keep on having to click around to find classes.


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 14:02:41 2006
From: jira-events at jboss.com (Prabhat Jha (JIRA))
Date: Fri, 29 Sep 2006 14:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3722) on Windows,
 org.jboss.test.naming.test.SimpleUnitTestCase fail
In-Reply-To: <18049202.1159480242340.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30208381.1159552961995.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3722?page=comments#action_12344342 ] 
            
Prabhat Jha commented on JBAS-3722:
-----------------------------------

This test passed when I ran with one-test. Either I messed up ip address or udpGroup while running test yesterday or someting got fixed today. We will see if this happens again during the entire test run in windows.

> on Windows, org.jboss.test.naming.test.SimpleUnitTestCase fail
> --------------------------------------------------------------
>
>                 Key: JBAS-3722
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3722
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Naming
>    Affects Versions: JBossAS-4.0.5.GA
>         Environment: Windows 2003 - dev28 in qa lab, Sun jdk1.4.2
>            Reporter: Prabhat Jha
>         Assigned To: Scott M Stark
>             Fix For: JBossAS-4.0.5.GA
>
>
> testHaParitionName and testDiscoveryPort of org.jboss.test.naming.test.SimpleUnitTestCase fail with :
> javax.naming.CommunicationException: Could not obtain connection to any of these urls: 10.16.56.139:65535 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]]
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1414)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:347)
> 	at org.jboss.test.naming.test.SimpleUnitTestCase.testDiscoveryPort(SimpleUnitTestCase.java:284)
> Caused by: javax.naming.CommunicationException: Failed to connect to server 10.16.56.139:65535 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:269)
> 	at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1385)
> 	... 19 more
> Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server 10.16.56.139:65535 [Root exception is java.net.ConnectException: Connection refused: connect]
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:243)
> 	... 20 more
> Caused by: java.net.ConnectException: Connection refused: connect
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
> 	at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
> 	at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
> 	at java.net.Socket.connect(Socket.java:461)
> 	at java.net.Socket.connect(Socket.java:411)
> 	at java.net.Socket.<init>(Socket.java:310)
> 	at java.net.Socket.<init>(Socket.java:212)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
> 	at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
> 	at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239)

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 14:29:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 29 Sep 2006 14:29:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBCACHE-650)
	SharedStoreCacheLoader
Message-ID: <30043674.1159554581764.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-650?page=all ]

Galder Zamarreno resolved JBCACHE-650.
--------------------------------------

    Resolution: Done

[JBCACHE-650] - SharedStoreCacheLoader refactored to SingletonStoreCacheLoader 
adding the ability to push the in-memory state to the underlying cache loader when 
assuming the coordinator role. Created AbstractDelegatingCacheLoader class that 
contains the basic delegating functionality. SingletonStoreCacheLoader and 
AsyncCacheLoader now extend this class. Necessary configuration options added 
and documentation has been updated to include explanation. Two singleton cache 
sample configurations added too.

> SharedStoreCacheLoader
> ----------------------
>
>                 Key: JBCACHE-650
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-650
>             Project: JBoss Cache
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2
>            Reporter: Bela Ban
>         Assigned To: Galder Zamarreno
>             Fix For: 2.0.0
>
>   Original Estimate: 3 days
>          Time Spent: 4 days
>  Remaining Estimate: 0 minutes
>
> Reactive this loader, which stores modifications only if it is the current coordinator.  In addition, it should (configurable via a flag) dump the entire in-memory contents into the file system, overwriting whatever is there, when it becomes coordinator. This is only possible though if no eviction has been defined

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 14:32:41 2006
From: jira-events at jboss.com (Galder Zamarreno (JIRA))
Date: Fri, 29 Sep 2006 14:32:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBCACHE-644) FileCacheLoader
 fails if FQN contains illegal/too many characters
Message-ID: <21814320.1159554761720.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBCACHE-644?page=all ]

Galder Zamarreno updated JBCACHE-644:
-------------------------------------

    Priority: Major  (was: Minor)

changed priority in order for it to appear at the top of my tasks

> FileCacheLoader fails if FQN contains illegal/too many characters
> -----------------------------------------------------------------
>
>                 Key: JBCACHE-644
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-644
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Cache loaders
>    Affects Versions: 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4beta, 1.3.0, 1.2.4, 1.2.4SP1, 1.2.4SP2, 1.3.0.SP1, 1.3.0.SP2
>         Environment: Windows XP
>            Reporter: Amit Kasher
>         Assigned To: Galder Zamarreno
>             Fix For: 2.0.0
>
>
> When putting FQNs that are too long to become filenames, or that contain illlegal characters for filenames (semicolon, for example), the FileCacheLoader throws an IOException.
> The FileCacheLoader should encode the FQN string so that it is a valid filename.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:38:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15723842.1159558721696.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=comments#action_12344349 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-564:
---------------------------------------------

Right. This is what I meant by "investigate".

The pre-bug report code didn't do any check and it was allowing unsubscribing a durable subscription with active consumers.


> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.2.0.Alpha1, 1.0.1.CR6
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:41:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:41:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7716808.1159558902378.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-525:
-----------------------------------------

             

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:41:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:41:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16175225.1159558902715.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov updated JBMESSAGING-525:
----------------------------------------

    Fix Version/s: 1.2.0.Alpha1
                       (was: 1.0.1.CR5)
                       (was: 1.2.0.Beta1)

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 15:41:43 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Fri, 29 Sep 2006 15:41:43 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-525)
 postgresql-persistence-service.xml contains invalid SQL syntax
In-Reply-To: <7474051.1156168425172.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10879497.1159558903065.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-525?page=all ]

Ovidiu Feodorov closed JBMESSAGING-525.
---------------------------------------

    Resolution: Done

shited up to Alpha1

> postgresql-persistence-service.xml contains invalid SQL syntax
> --------------------------------------------------------------
>
>                 Key: JBMESSAGING-525
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-525
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Configuration and Management
>    Affects Versions: 1.0.1.CR4
>         Environment: JBoss 4.0.4.GA, JBoss Messaging 1.0.1.CR4, PostgreSQL 8.1
>            Reporter: Takayoshi Kimura
>         Assigned To: Clebert Suconic
>             Fix For: 1.2.0.Alpha1
>
>         Attachments: postgresql-persistence-service.xml.patch
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> The UPDATE_UNRELIABLE_CHANNELCOUNT SQL in postgresql-persistence-service.xml uses "UPDATE tablename alias" syntax but PostgreSQL does not support this syntax.
> http://www.postgresql.org/docs/8.1/static/sql-update.html
> http://www.postgresql.org/docs/7.4/static/sql-update.html
> To fix this, simply remove the aliases from the SQL.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 17:42:41 2006
From: jira-events at jboss.com (Scott M Stark (JIRA))
Date: Fri, 29 Sep 2006 17:42:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3729) Add alternate run-as
 mappings for container callbacks
Message-ID: <19261563.1159566161609.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add alternate run-as mappings for container callbacks
-----------------------------------------------------

                 Key: JBAS-3729
                 URL: http://jira.jboss.com/jira/browse/JBAS-3729
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: EJB2, EJB3, Security, Web (Tomcat) service
    Affects Versions: JBossAS-4.0.4.GA
            Reporter: Scott M Stark
         Assigned To: Scott M Stark
             Fix For: JBossAS-4.0.6.CR1


Other app servers support anlternate run-as semantics from the container init/destroy lifecycle callbacks. Weblogic for example:
http://e-docs.bea.com/wls/docs81/webapp/weblogic_xml.html#1041058

This is an equivalent of <run-as> for init method for servlets. For example:
      <init-as>
        <servlet-name>FooServlet</servlet-name>
        <principal-name>joe</principal-name>
      </init-as>

   <destroy-as>
    <servlet-name>BarServlet</servlet-name>
    <principal-name>bob</principal-name>
  </destroy-as>

This would allow more control over how these methods interact with secured resources. Similar options could be added for ejb lifecycle methods as well.


-- 
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

        


From jira-events at jboss.com  Fri Sep 29 18:11:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBSEAM-28) Context Listeners
Message-ID: <32129385.1159567901511.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=all ]

Gavin King updated JBSEAM-28:
-----------------------------

    Fix Version/s: 1.1
         Priority: Major  (was: Minor)

I have implemented the following events:


org.jboss.seam.preSetVariable.<name>
org.jboss.seam.postSetVariable.<name>
org.jboss.seam.preRemoveVariable.<name>
org.jboss.seam.postRemoveVariable.<name>

org.jboss.seam.preDestroyContext.<SCOPE>
org.jboss.seam.postDestroyContext.<SCOPE>

org.jboss.seam.beginConversation
org.jboss.seam.endConversation

org.jboss.seam.beginPageflow.<name>

org.jboss.seam.createProcess.<name>
org.jboss.seam.initProcess.<name>

org.jboss.seam.initTask.<name>
org.jboss.seam.startTask.<name>
org.jboss.seam.endTask.<name>

org.jboss.seam.postConstruct.<name>
org.jboss.seam.preDestroy.<name>
org.jboss.seam.prePassivate.<name>
org.jboss.seam.postActivate.<name>

Still need to do:

org.jboss.seam.preCreateContext.<SCOPE>
org.jboss.seam.postCreateContext.<SCOPE>


> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:14:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:14:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-28) Context Listeners
Message-ID: <10378144.1159568081615.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=comments#action_12344354 ] 
            
Gavin King commented on JBSEAM-28:
----------------------------------

Or should it be postCreate/preDestroy instead of / in addition to the EJB events?

> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:53:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBSEAM-28) Context Listeners
Message-ID: <30441782.1159570421726.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=all ]

Gavin King closed JBSEAM-28.
----------------------------

    Resolution: Done

> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:53:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBSEAM-28) Context Listeners
Message-ID: <20441322.1159570421604.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBSEAM-28?page=comments#action_12344355 ] 
            
Gavin King commented on JBSEAM-28:
----------------------------------

done and committed except for the create context events

> Context Listeners
> -----------------
>
>                 Key: JBSEAM-28
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-28
>             Project: JBoss Seam
>          Issue Type: Feature Request
>          Components: Core
>            Reporter: Gavin King
>         Assigned To: Gavin King
>             Fix For: 1.1
>
>
> ContextListener objects would receive notifications of events like destroyContext(), getValue(), setValue(), 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

        


From jira-events at jboss.com  Fri Sep 29 18:53:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 18:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-373) create context
	events
Message-ID: <29461495.1159570421851.JavaMail.jira@cloud.prod.atl2.jboss.com>

create context events
---------------------

                 Key: JBSEAM-373
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-373
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


We have events for context destruction, we also need them for creation of contexts.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 19:11:41 2006
From: jira-events at jboss.com (Gavin King (JIRA))
Date: Fri, 29 Sep 2006 19:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBSEAM-374) Normalize the event
	model
Message-ID: <4193874.1159571501566.JavaMail.jira@cloud.prod.atl2.jboss.com>

Normalize the event model
-------------------------

                 Key: JBSEAM-374
                 URL: http://jira.jboss.com/jira/browse/JBSEAM-374
             Project: JBoss Seam
          Issue Type: Feature Request
          Components: Core
            Reporter: Gavin King
         Assigned To: Gavin King
             Fix For: 1.1


Currently some events can be handled by either an @Observer method, or a method binding in events.xml. Ideally we would like this to be true for ALL events, but for now our integration with JSF and jBPM is not quite that deep. Nevertheless, there are some things we could do to allow a more consistent model where everything can be handled by either a method binding or an annotated method:


(1) Rebuild the page actions functionality on top of the Seam event bus - defining standard org.jboss.seam.page.<viewId> events that can be handled via @Observer("org.jboss.seam.page./myViewId.xhtml")

(2) Introduce "outcome observers" for JSF: if I have <h:commandButton action="myOutcome"/>, allow us to handle it using @Observer("org.jboss.seam.outcome.myOutcome")

(3) Ditto for jBPM: if I have <transition name="myTransition" ... />, allow us to handle it using @Observer("org.jboss.seam.transition.myTransition")

(4) Finally, introduce annotations layered over @Observer: @RenderPage("/myViewId.xhtml"), @Outcome("myOutcome"), @Transition("myTransition")



-- 
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

        


From jira-events at jboss.com  Fri Sep 29 19:53:41 2006
From: jira-events at jboss.com (jarkko Lietolahti (JIRA))
Date: Fri, 29 Sep 2006 19:53:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3730) Use caching,
 serialization and snapshots to speedup JBoss AS startup
Message-ID: <5590539.1159574021694.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use caching, serialization and snapshots to speedup JBoss AS startup
--------------------------------------------------------------------

                 Key: JBAS-3730
                 URL: http://jira.jboss.com/jira/browse/JBAS-3730
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: jarkko Lietolahti


When using JBoss AS in development i feel that the startup time of AS is waaayyy too long, it's something between 20 seconds (very trimmed down version, almost ripped off of all the required services) to 1 minute on my 2GHz laptop with 2 gigabytes of memory. 

So speed up the startup time of standard(aka default with ejb3) JBoss AS. By this i mean speed up the startups especially in development environments. It's ok for the initial startup after clean installation to take more time. But during "clean" startup JBoss AS should use caching, serialization, snapshots and all the available ways to make the next startup lightning fast. By lightning fast i mean 2 to 5 seconds.

This can ofcourse happen if nothing has changed in the configuration, which is usually the case during development where the AS has been shutdown for reasons like unrecorable error (like hanging transactions), severe hot code replace error (after which the as environment becomes too unstable to continue function correctly), or some configuration change which cannot be done while the as is "online".

>From boot.log and system.log i can see that there are places where JBoss AS could "cache"/serialize/etc stuff and on next startup use the information from the "cache". I've been trying to do a graph of JBoss AS startup based on the logs to see where the startup process spends it moments.

Maybe it would be possible to "cache" RepositoryClassLoader contents and avoid the cost of scanning default/lib directory for jar libaries which stay unchanged for most of the start-stop cycle (atleast during certain development phases).
 
I also noticed on a dual core machine some of the activity during startup/deployment doesn't scale very well. At these phases total cpu usage is ~48-52 %, which indicates that the activity doesn't get the additional benefit of multi core / cpu environment.

Of course, a mechanism to detect a change in the configuration/etc should be build also which would detect a change in configuration and reload the changed information.

-- 
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

        


From jira-events at jboss.com  Fri Sep 29 19:56:41 2006
From: jira-events at jboss.com (jarkko Lietolahti (JIRA))
Date: Fri, 29 Sep 2006 19:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBAS-3730) Use caching,
 serialization and snapshots to speedup JBoss AS startup
In-Reply-To: <5590539.1159574021694.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16802755.1159574201656.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBAS-3730?page=comments#action_12344356 ] 
            
jarkko Lietolahti commented on JBAS-3730:
-----------------------------------------

Caching of default/lib RepositoryClassLoader is just an example. 

> Use caching, serialization and snapshots to speedup JBoss AS startup
> --------------------------------------------------------------------
>
>                 Key: JBAS-3730
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3730
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: jarkko Lietolahti
>
> When using JBoss AS in development i feel that the startup time of AS is waaayyy too long, it's something between 20 seconds (very trimmed down version, almost ripped off of all the required services) to 1 minute on my 2GHz laptop with 2 gigabytes of memory. 
> So speed up the startup time of standard(aka default with ejb3) JBoss AS. By this i mean speed up the startups especially in development environments. It's ok for the initial startup after clean installation to take more time. But during "clean" startup JBoss AS should use caching, serialization, snapshots and all the available ways to make the next startup lightning fast. By lightning fast i mean 2 to 5 seconds.
> This can ofcourse happen if nothing has changed in the configuration, which is usually the case during development where the AS has been shutdown for reasons like unrecorable error (like hanging transactions), severe hot code replace error (after which the as environment becomes too unstable to continue function correctly), or some configuration change which cannot be done while the as is "online".
> From boot.log and system.log i can see that there are places where JBoss AS could "cache"/serialize/etc stuff and on next startup use the information from the "cache". I've been trying to do a graph of JBoss AS startup based on the logs to see where the startup process spends it moments.
> Maybe it would be possible to "cache" RepositoryClassLoader contents and avoid the cost of scanning default/lib directory for jar libaries which stay unchanged for most of the start-stop cycle (atleast during certain development phases).
>  
> I also noticed on a dual core machine some of the activity during startup/deployment doesn't scale very well. At these phases total cpu usage is ~48-52 %, which indicates that the activity doesn't get the additional benefit of multi core / cpu environment.
> Of course, a mechanism to detect a change in the configuration/etc should be build also which would detect a change in configuration and reload the changed information.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:47:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 00:47:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3731) The default
 ServiceBindingManager's sample bindings file should override JBoss
 Messaging's Connector configuration
Message-ID: <9539431.1159591662176.JavaMail.jira@cloud.prod.atl2.jboss.com>

The default ServiceBindingManager's sample bindings file should override JBoss Messaging's Connector configuration
------------------------------------------------------------------------------------------------------------------

                 Key: JBAS-3731
                 URL: http://jira.jboss.com/jira/browse/JBAS-3731
             Project: JBoss Application Server
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Other
    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
            Reporter: Ovidiu Feodorov
             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta


The default ServiceBindingManager's sample bindings file (${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml) should contain <service-config> entries that would override JBoss Messaging's Connector configuration.

The <service-config> should be present in all <server> bindings ("ports-default", "ports-01", "ports-02", "ports-03").

Suggested <service-config> entries:

"ports-default":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4457/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4457"/>
 </service-config></server>

"ports-01":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4557/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4557"/>
 </service-config></server>


"ports-02":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4657/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4657"/>
 </service-config></server>


"ports-03":

 <service-config name="jboss.messaging:service=Connector,transport=socket"
                              delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
      <delegate-config>
           <attribute name="InvokerLocator">socket://${jboss.bind.address}:4757/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
      </delegate-config>
      <binding port="4757"/>
 </service-config></server>








-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:53:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 00:53:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-438) Allow ports
 used by JBossMessaging to be mapped using ServiceBindingManager
In-Reply-To: <4635607.1153322771332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12768324.1159592022267.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBMESSAGING-438?page=comments#action_12344359 ] 
            
Ovidiu Feodorov commented on JBMESSAGING-438:
---------------------------------------------

The clustering installation script deals with this issue by making a local copy of sample-bindings.xml ($JBOSS_HOME/server/<config-name>/conf/binding-manager.xml) and adding the overrides there.

The problem is that overrides are too brittle: Remoting Connector doesn't support a port reconfiguration on the fly (at least not the way ServiceBindingManager does it), so I need to hard-code full InvokerLocator configurations (with host, port, serializationType, leasePeriod, etc) in binding-manager.xml.

The correct solution of the problem is to modify the Remoting Connector to allow port and host reconfigurations on the fly, in a manner compatible with ServiceBindingManager.

> Allow ports used by JBossMessaging to be mapped using ServiceBindingManager
> ---------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-438
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-438
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Tim Fox
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.2.0.CR1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:56:42 2006
From: jira-events at jboss.com (Leo Liang (JIRA))
Date: Sat, 30 Sep 2006 00:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBRULES-506) Exception thrown
 when retract, reassert and retract again
Message-ID: <18021626.1159592202304.JavaMail.jira@cloud.prod.atl2.jboss.com>

Exception thrown when retract, reassert and retract again
---------------------------------------------------------

                 Key: JBRULES-506
                 URL: http://jira.jboss.com/jira/browse/JBRULES-506
             Project: JBoss Rules
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.0.4, 3.0.1
            Reporter: Leo Liang
         Assigned To: Mark Proctor
         Attachments: Fact.java, test.drl, TestDriver.java

In one rule retract the object and re-assert it, then retract the object again in the following activated rule. A null pointer exception will occur at this time.

java.lang.NullPointerException
	at org.drools.reteoo.TerminalNode.retractTuple(TerminalNode.java:216)
	at org.drools.reteoo.LeftInputAdapterNode.retractObject(LeftInputAdapterNode.java:207)
	at org.drools.reteoo.ObjectSource.propagateRetractObject(ObjectSource.java:141)
	at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:180)
	at org.drools.reteoo.Rete.retractObject(Rete.java:150)
	at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:207)
	at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:77)
	at org.drools.common.AbstractWorkingMemory.retractObject(AbstractWorkingMemory.java:668)
	at org.drools.base.DefaultKnowledgeHelper.retractObject(DefaultKnowledgeHelper.java:86)
	at com.ericsson.ruletest.debug.Rule_test2_0.consequence(Rule_test2_0.java:8)
	at com.ericsson.ruletest.debug.Rule_test2_0ConsequenceInvoker.evaluate(Rule_test2_0ConsequenceInvoker.java:22)
	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:437)
	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:269)
	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:256)
	at com.ericsson.ruletest.TestDriver.main(TestDriver.java:26)

The given test case is the the simplified from my production code.

--------------- test.drl ------------------------

package com.ericsson.ruletest.debug

import com.ericsson.ruletest.Fact;

rule "test1"
	salience 10
	no-loop true
    when
        input:Fact();
    then
    	retract(input);
	assert(input);
end;


rule "test2"
	salience 0
	no-loop true
    when
        input:Fact();
    then
	retract(input);
end;




-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:56:42 2006
From: jira-events at jboss.com (Leo Liang (JIRA))
Date: Sat, 30 Sep 2006 00:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-506) Exception thrown
 when retract, reassert and retract again
In-Reply-To: <18021626.1159592202304.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13494388.1159592202496.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-506?page=all ]

Leo Liang updated JBRULES-506:
------------------------------

    Attachment: TestDriver.java

> Exception thrown when retract, reassert and retract again
> ---------------------------------------------------------
>
>                 Key: JBRULES-506
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-506
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.4, 3.0.1
>            Reporter: Leo Liang
>         Assigned To: Mark Proctor
>         Attachments: Fact.java, test.drl, TestDriver.java
>
>
> In one rule retract the object and re-assert it, then retract the object again in the following activated rule. A null pointer exception will occur at this time.
> java.lang.NullPointerException
> 	at org.drools.reteoo.TerminalNode.retractTuple(TerminalNode.java:216)
> 	at org.drools.reteoo.LeftInputAdapterNode.retractObject(LeftInputAdapterNode.java:207)
> 	at org.drools.reteoo.ObjectSource.propagateRetractObject(ObjectSource.java:141)
> 	at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:180)
> 	at org.drools.reteoo.Rete.retractObject(Rete.java:150)
> 	at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:207)
> 	at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:77)
> 	at org.drools.common.AbstractWorkingMemory.retractObject(AbstractWorkingMemory.java:668)
> 	at org.drools.base.DefaultKnowledgeHelper.retractObject(DefaultKnowledgeHelper.java:86)
> 	at com.ericsson.ruletest.debug.Rule_test2_0.consequence(Rule_test2_0.java:8)
> 	at com.ericsson.ruletest.debug.Rule_test2_0ConsequenceInvoker.evaluate(Rule_test2_0ConsequenceInvoker.java:22)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:437)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:269)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:256)
> 	at com.ericsson.ruletest.TestDriver.main(TestDriver.java:26)
> The given test case is the the simplified from my production code.
> --------------- test.drl ------------------------
> package com.ericsson.ruletest.debug
> import com.ericsson.ruletest.Fact;
> rule "test1"
> 	salience 10
> 	no-loop true
>     when
>         input:Fact();
>     then
>     	retract(input);
> 	assert(input);
> end;
> rule "test2"
> 	salience 0
> 	no-loop true
>     when
>         input:Fact();
>     then
> 	retract(input);
> end;

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 00:56:42 2006
From: jira-events at jboss.com (Leo Liang (JIRA))
Date: Sat, 30 Sep 2006 00:56:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBRULES-506) Exception thrown
 when retract, reassert and retract again
In-Reply-To: <18021626.1159592202304.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20434750.1159592202710.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBRULES-506?page=all ]

Leo Liang updated JBRULES-506:
------------------------------

    Attachment: Fact.java
                test.drl

> Exception thrown when retract, reassert and retract again
> ---------------------------------------------------------
>
>                 Key: JBRULES-506
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-506
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.0.4, 3.0.1
>            Reporter: Leo Liang
>         Assigned To: Mark Proctor
>         Attachments: Fact.java, test.drl, TestDriver.java
>
>
> In one rule retract the object and re-assert it, then retract the object again in the following activated rule. A null pointer exception will occur at this time.
> java.lang.NullPointerException
> 	at org.drools.reteoo.TerminalNode.retractTuple(TerminalNode.java:216)
> 	at org.drools.reteoo.LeftInputAdapterNode.retractObject(LeftInputAdapterNode.java:207)
> 	at org.drools.reteoo.ObjectSource.propagateRetractObject(ObjectSource.java:141)
> 	at org.drools.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:180)
> 	at org.drools.reteoo.Rete.retractObject(Rete.java:150)
> 	at org.drools.reteoo.ReteooRuleBase.retractObject(ReteooRuleBase.java:207)
> 	at org.drools.reteoo.ReteooWorkingMemory.doRetract(ReteooWorkingMemory.java:77)
> 	at org.drools.common.AbstractWorkingMemory.retractObject(AbstractWorkingMemory.java:668)
> 	at org.drools.base.DefaultKnowledgeHelper.retractObject(DefaultKnowledgeHelper.java:86)
> 	at com.ericsson.ruletest.debug.Rule_test2_0.consequence(Rule_test2_0.java:8)
> 	at com.ericsson.ruletest.debug.Rule_test2_0ConsequenceInvoker.evaluate(Rule_test2_0ConsequenceInvoker.java:22)
> 	at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:437)
> 	at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:269)
> 	at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:256)
> 	at com.ericsson.ruletest.TestDriver.main(TestDriver.java:26)
> The given test case is the the simplified from my production code.
> --------------- test.drl ------------------------
> package com.ericsson.ruletest.debug
> import com.ericsson.ruletest.Fact;
> rule "test1"
> 	salience 10
> 	no-loop true
>     when
>         input:Fact();
>     then
>     	retract(input);
> 	assert(input);
> end;
> rule "test2"
> 	salience 0
> 	no-loop true
>     when
>         input:Fact();
>     then
> 	retract(input);
> end;

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 03:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 03:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3699) Fix testsuite OOMEs
In-Reply-To: <30073859.1159258561710.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15441859.1159601921709.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3699?page=all ]

Dimitris Andreadis closed JBAS-3699.
------------------------------------

    Resolution: Done
      Assignee: Dimitris Andreadis

OOMEs gone.

> Fix testsuite OOMEs
> -------------------
>
>                 Key: JBAS-3699
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3699
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Test Suite
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA
>
>
> Container task to indentify and fix testsuite OOMEs

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 04:32:42 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 04:32:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3676) Upgrade jboss-common
	to 1.0.0.GA
In-Reply-To: <33492596.1158763621630.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18379539.1159605162235.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3676?page=all ]

Dimitris Andreadis closed JBAS-3676.
------------------------------------

    Resolution: Done

Done

> Upgrade jboss-common to 1.0.0.GA
> --------------------------------
>
>                 Key: JBAS-3676
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3676
>             Project: JBoss Application Server
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Other
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.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

        


From jira-events at jboss.com  Sat Sep 30 06:26:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 06:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-561) Write a simple
 example
 (distributed topic) and include it in the set shipped with the release
In-Reply-To: <27083718.1159475022538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24260273.1159612002150.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-561?page=all ]

Ovidiu Feodorov updated JBMESSAGING-561:
----------------------------------------

    Summary: Write a simple example (distributed topic) and include it in the set shipped with the release  (was: Write two simple examples (distributed queue/topic) and include them in the set shipped with the release)

> Write a simple example (distributed topic) and include it in the set shipped with the release
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-561
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-561
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 06:26:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 06:26:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-562) Adjust the
 installation script to support a clustered installation
In-Reply-To: <2558336.1159475381657.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26410722.1159612002297.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-562?page=all ]

Ovidiu Feodorov closed JBMESSAGING-562.
---------------------------------------

    Resolution: Done

> Adjust the installation script to support a clustered installation
> ------------------------------------------------------------------
>
>                 Key: JBMESSAGING-562
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-562
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 06:29:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 06:29:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBMESSAGING-566) Decide on
 validity of
 DurableSubscriberTest.testDurableSubscriptionDifferentNoLocal()
Message-ID: <32984702.1159612182070.JavaMail.jira@cloud.prod.atl2.jboss.com>

Decide on validity of DurableSubscriberTest.testDurableSubscriptionDifferentNoLocal()
-------------------------------------------------------------------------------------

                 Key: JBMESSAGING-566
                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-566
             Project: JBoss Messaging
          Issue Type: Task
          Components: Tests and Performance
            Reporter: Ovidiu Feodorov
         Assigned To: Ovidiu Feodorov
             Fix For: 1.2.0.Alpha2


DurableSubscriberTest.testDurableSubscriptionDifferentNoLocal() is temporarily commented out until its validity is established. Re-enable the test or delete it, depending on the conclusion.


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 07:06:41 2006
From: jira-events at jboss.com (Esteban Schifman (JIRA))
Date: Sat, 30 Sep 2006 07:06:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-157) Socket listeners
 might introduce
 a port conflict when reinstantiated by the controlling GpListener at
 parameter reload time
Message-ID: <16566909.1159614401806.JavaMail.jira@cloud.prod.atl2.jboss.com>

Socket listeners might introduce a port conflict when reinstantiated by the controlling GpListener at parameter reload time
---------------------------------------------------------------------------------------------------------------------------

                 Key: JBESB-157
                 URL: http://jira.jboss.com/jira/browse/JBESB-157
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: ESB Core
            Reporter: Esteban Schifman
         Assigned To: Esteban Schifman
             Fix For: 4.0


GpListener has at present two mechanisms to reload it's configuration parameters:  a) timer driven  2) message driven.

At parameter reload time, the controlling instance of GpListener will try to instantiate new child processes according to the new configuration values.  It will allow active child threads to gracetully finish.

New listener classes that are accepting connections on specific sockets will have a conflict when the new instance tries to listen on a port that is being used by the active instance.


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:11:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-563) Update the
 documentation with a Clustering Intro
In-Reply-To: <284336.1159475381808.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18701286.1159618301669.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-563?page=all ]

Ovidiu Feodorov updated JBMESSAGING-563:
----------------------------------------

    Assignee: Tim Fox  (was: Ovidiu Feodorov)

> Update the documentation with a Clustering Intro
> ------------------------------------------------
>
>                 Key: JBMESSAGING-563
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-563
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:11:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-563) Update the
 documentation with a Clustering Intro
In-Reply-To: <284336.1159475381808.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14220693.1159618301841.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-563?page=all ]

Ovidiu Feodorov closed JBMESSAGING-563.
---------------------------------------

    Resolution: Done

> Update the documentation with a Clustering Intro
> ------------------------------------------------
>
>                 Key: JBMESSAGING-563
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-563
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:11:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:11:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-561) Write a simple
 example
 (distributed topic) and include it in the set shipped with the release
In-Reply-To: <27083718.1159475022538.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25244249.1159618301966.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-561?page=all ]

Ovidiu Feodorov closed JBMESSAGING-561.
---------------------------------------

    Resolution: Done

> Write a simple example (distributed topic) and include it in the set shipped with the release
> ---------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-561
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-561
>             Project: JBoss Messaging
>          Issue Type: Feature Request
>          Components: Tests and Performance
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Critical
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 08:26:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 08:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-444) Release
	1.2.0.Alpha1
In-Reply-To: <4902145.1153769531475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18271426.1159619201651.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-444?page=all ]

Ovidiu Feodorov closed JBMESSAGING-444.
---------------------------------------

    Resolution: Done

> Release 1.2.0.Alpha1
> --------------------
>
>                 Key: JBMESSAGING-444
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-444
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>            Priority: Blocker
>             Fix For: 1.2.0.Alpha1
>
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 12:17:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-333) Provide SO_LINGER for
	TCP/TCP_NIO
Message-ID: <11431434.1159633061692.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide SO_LINGER for TCP/TCP_NIO
---------------------------------

                 Key: JGRP-333
                 URL: http://jira.jboss.com/jira/browse/JGRP-333
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 2.3 SP1
            Reporter: Bela Ban
         Assigned To: Bela Ban
            Priority: Minor
             Fix For: 2.4


Implemented as 'linger' in TCP and TCP_NIO

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 12:20:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JGRP-333) Provide SO_LINGER
	for TCP/TCP_NIO
In-Reply-To: <11431434.1159633061692.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19843082.1159633241508.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JGRP-333?page=all ]

Bela Ban resolved JGRP-333.
---------------------------

    Resolution: Done

> Provide SO_LINGER for TCP/TCP_NIO
> ---------------------------------
>
>                 Key: JGRP-333
>                 URL: http://jira.jboss.com/jira/browse/JGRP-333
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.3 SP1
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.4
>
>
> Implemented as 'linger' in TCP and TCP_NIO

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 12:20:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JGRP-334) Option to pick random
 port in TCP/TCP_NIO
Message-ID: <20108966.1159633241624.JavaMail.jira@cloud.prod.atl2.jboss.com>

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

        


From jira-events at jboss.com  Sat Sep 30 12:23:41 2006
From: jira-events at jboss.com (Bela Ban (JIRA))
Date: Sat, 30 Sep 2006 12:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JGRP-334) Option to pick
 random port in TCP/TCP_NIO
In-Reply-To: <20108966.1159633241624.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18821183.1159633421616.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JGRP-334?page=comments#action_12344364 ] 
            
Bela Ban commented on JGRP-334:
-------------------------------

Of course, this works only with MPING or TCPGOSSIP. We need to have a little sanity test which terminates on startup if we have an incorrect discovery protocol (e.g. TCPPING) and start_port is not set !

> 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

        


From jira-events at jboss.com  Sat Sep 30 14:05:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-559) Add a
 4.0.5.CR1 EJB3 smoke test
In-Reply-To: <31350343.1159295201477.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11854397.1159639541802.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-559?page=all ]

Ovidiu Feodorov updated JBMESSAGING-559:
----------------------------------------

    Fix Version/s: 1.0.1.GA
                       (was: 1.0.1.CR6)

> Add a 4.0.5.CR1 EJB3 smoke test
> -------------------------------
>
>                 Key: JBMESSAGING-559
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-559
>             Project: JBoss Messaging
>          Issue Type: Task
>            Reporter: Ovidiu Feodorov
>         Assigned To: Ovidiu Feodorov
>             Fix For: 1.0.1.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

        


From jira-events at jboss.com  Sat Sep 30 14:05:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8126648.1159639541961.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Ovidiu Feodorov reopened JBMESSAGING-564:
-----------------------------------------

             

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:05:42 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:05:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBMESSAGING-564)
 Session.unsubscribe()
 leaves an active associated consumer (durable subscriber) in an undefined
 state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <207083.1159639542174.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Ovidiu Feodorov updated JBMESSAGING-564:
----------------------------------------

    Fix Version/s: 1.0.1.GA
                       (was: 1.0.1.CR6)
                       (was: 1.2.0.Alpha1)

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:08:41 2006
From: jira-events at jboss.com (Ovidiu Feodorov (JIRA))
Date: Sat, 30 Sep 2006 14:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBMESSAGING-564)
 Session.unsubscribe() leaves
 an active associated consumer (durable subscriber) in an undefined state
In-Reply-To: <8992285.1159486721649.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3594189.1159639721564.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-564?page=all ]

Ovidiu Feodorov closed JBMESSAGING-564.
---------------------------------------

    Resolution: Won't Fix

> Session.unsubscribe() leaves an active associated consumer (durable subscriber) in an undefined state
> -----------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-564
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-564
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: JMS Facade
>    Affects Versions: 1.2.0.Alpha1, 1.0.1.CR5
>            Reporter: Ovidiu Feodorov
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.0.1.GA
>
>
> Invoking Session.unsubscribe() for a durable subscription for which there is an active associated consumer (durable subscriber) leaves it in an undefined state. The consumer is open, but there's no subscription it can possibly receive messages from.
> Investigate.
> In the 1.2.0.Alpha code, this leads to failure to close a connection that has contains such a consumer. See DurableSubscriberTest.testUnsubscribe().

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:26:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
In-Reply-To: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11256934.1159640801625.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3727?page=all ]

Dimitris Andreadis reassigned JBAS-3727:
----------------------------------------

    Assignee: Dimitris Andreadis  (was: Scott M Stark)

> NPE on context classloader changing in EJB container when caller doesn't have a context classloader
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3727
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> The following code in org.jboss.ejb.Container
> doesn't work if the caller doesn't have a context classloader,
> e.g. it is using the bootstrap classloader as its classloader on the Sun JDK
>       ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
>       long start = System.currentTimeMillis();
>       Method m = null;
>       boolean setCl = false;
>       Object type = null;
>       String contextID = getJaccContextID();
>       try
>       {
>          if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
>          {
>             setCl = true;
>             SecurityActions.setContextClassLoader(this.classLoader);
>          }
> The classloaders should be reversed, since the ejb classloader can never be null.
> Is there a reason for this optimization? I'd imagine the comparison of classloaders
> is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:35:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:35:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
In-Reply-To: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18379860.1159641341689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3727?page=all ]

Dimitris Andreadis updated JBAS-3727:
-------------------------------------

    Affects Version/s: JBossAS-3.2.8.SP1

> NPE on context classloader changing in EJB container when caller doesn't have a context classloader
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3727
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> The following code in org.jboss.ejb.Container
> doesn't work if the caller doesn't have a context classloader,
> e.g. it is using the bootstrap classloader as its classloader on the Sun JDK
>       ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
>       long start = System.currentTimeMillis();
>       Method m = null;
>       boolean setCl = false;
>       Object type = null;
>       String contextID = getJaccContextID();
>       try
>       {
>          if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
>          {
>             setCl = true;
>             SecurityActions.setContextClassLoader(this.classLoader);
>          }
> The classloaders should be reversed, since the ejb classloader can never be null.
> Is there a reason for this optimization? I'd imagine the comparison of classloaders
> is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBAS-3732) Remove
 classloader.equals optimization
Message-ID: <3748725.1159641521636.JavaMail.jira@cloud.prod.atl2.jboss.com>

Remove classloader.equals optimization
--------------------------------------

                 Key: JBAS-3732
                 URL: http://jira.jboss.com/jira/browse/JBAS-3732
             Project: JBoss Application Server
          Issue Type: Sub-task
      Security Level: Public (Everyone can see)
          Components: EJB2
    Affects Versions: JBossAS-4.0.5.GA
            Reporter: Dimitris Andreadis
         Assigned To: Dimitris Andreadis
             Fix For: JBossAS-4.0.6.CR1


According to the parent issue, the classloader check optimization is probably unecessary, so remove it in the next CR release.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Updated: (JBAS-3732) Remove
 classloader.equals optimization
In-Reply-To: <3748725.1159641521636.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9029583.1159641521745.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3732?page=all ]

Dimitris Andreadis updated JBAS-3732:
-------------------------------------

    Priority: Minor  (was: Major)

> Remove classloader.equals optimization
> --------------------------------------
>
>                 Key: JBAS-3732
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3732
>             Project: JBoss Application Server
>          Issue Type: Sub-task
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.GA
>            Reporter: Dimitris Andreadis
>         Assigned To: Dimitris Andreadis
>            Priority: Minor
>             Fix For: JBossAS-4.0.6.CR1
>
>
> According to the parent issue, the classloader check optimization is probably unecessary, so remove it in the next CR release.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:38:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3727) NPE on context
 classloader
 changing in EJB container when caller doesn't have a context classloader
In-Reply-To: <425868.1159540541627.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25361105.1159641521940.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3727?page=all ]

Dimitris Andreadis closed JBAS-3727.
------------------------------------

    Fix Version/s: JBossAS-3.2.8.SP2
       Resolution: Done

I switched the equals order and made a subtasks to try remove the optimazation in the next CR release.

> NPE on context classloader changing in EJB container when caller doesn't have a context classloader
> ---------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3727
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3727
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: EJB2
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-3.2.8.SP1
>            Reporter: Adrian Brock
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2
>
>
> The following code in org.jboss.ejb.Container
> doesn't work if the caller doesn't have a context classloader,
> e.g. it is using the bootstrap classloader as its classloader on the Sun JDK
>       ClassLoader callerClassLoader = SecurityActions.getContextClassLoader();
>       long start = System.currentTimeMillis();
>       Method m = null;
>       boolean setCl = false;
>       Object type = null;
>       String contextID = getJaccContextID();
>       try
>       {
>          if (!callerClassLoader.equals(classLoader)) // !!! callerClassLoader is null !!!
>          {
>             setCl = true;
>             SecurityActions.setContextClassLoader(this.classLoader);
>          }
> The classloaders should be reversed, since the ejb classloader can never be null.
> Is there a reason for this optimization? I'd imagine the comparison of classloaders
> is likely to be more expensive that just setting the TCL in some cases????

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 14:56:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 14:56:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBAS-3731) The default
 ServiceBindingManager's sample bindings file should override JBoss
 Messaging's Connector configuration
In-Reply-To: <9539431.1159591662176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6850820.1159642601536.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3731?page=all ]

Dimitris Andreadis reassigned JBAS-3731:
----------------------------------------

    Assignee: Dimitris Andreadis

> The default ServiceBindingManager's sample bindings file should override JBoss Messaging's Connector configuration
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3731
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3731
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.GA
>
>
> The default ServiceBindingManager's sample bindings file (${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml) should contain <service-config> entries that would override JBoss Messaging's Connector configuration.
> The <service-config> should be present in all <server> bindings ("ports-default", "ports-01", "ports-02", "ports-03").
> Suggested <service-config> entries:
> "ports-default":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4457/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4457"/>
>  </service-config></server>
> "ports-01":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4557/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4557"/>
>  </service-config></server>
> "ports-02":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4657/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4657"/>
>  </service-config></server>
> "ports-03":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4757/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4757"/>
>  </service-config></server>

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:02:41 2006
From: jira-events at jboss.com (Dimitris Andreadis (JIRA))
Date: Sat, 30 Sep 2006 15:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBAS-3731) The default
 ServiceBindingManager's sample bindings file should override JBoss
 Messaging's Connector configuration
In-Reply-To: <9539431.1159591662176.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4093988.1159642961526.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBAS-3731?page=all ]

Dimitris Andreadis closed JBAS-3731.
------------------------------------

    Resolution: Done

Added the bindings as suggested in Branch_4_0 and HEAD

> The default ServiceBindingManager's sample bindings file should override JBoss Messaging's Connector configuration
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBAS-3731
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3731
>             Project: JBoss Application Server
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Other
>    Affects Versions: JBossAS-4.0.5.CR1, JBossAS-4.0.4.GA
>            Reporter: Ovidiu Feodorov
>         Assigned To: Dimitris Andreadis
>             Fix For: JBossAS-4.0.5.GA, JBossAS-5.0.0.Beta
>
>
> The default ServiceBindingManager's sample bindings file (${jboss.home.url}/docs/examples/binding-manager/sample-bindings.xml) should contain <service-config> entries that would override JBoss Messaging's Connector configuration.
> The <service-config> should be present in all <server> bindings ("ports-default", "ports-01", "ports-02", "ports-03").
> Suggested <service-config> entries:
> "ports-default":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4457/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4457"/>
>  </service-config></server>
> "ports-01":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4557/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4557"/>
>  </service-config></server>
> "ports-02":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4657/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4657"/>
>  </service-config></server>
> "ports-03":
>  <service-config name="jboss.messaging:service=Connector,transport=socket"
>                               delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
>       <delegate-config>
>            <attribute name="InvokerLocator">socket://${jboss.bind.address}:4757/?dataType=jms&amp;serializationtype=jms&amp;timeout=0&amp;leasePeriod=20000&amp;socket.check_connection=false&amp;marshaller=org.jboss.jms.server.remoting.JMSWireFormat&amp;unmarshaller=org.jboss.jms.server.remoting.JMSWireFormat</attribute>
>       </delegate-config>
>       <binding port="4757"/>
>  </service-config></server>

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:39:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:39:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-158) Update manuals on
 EPR and Message changes.
Message-ID: <21331127.1159645181720.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update manuals on EPR and Message changes.
------------------------------------------

                 Key: JBESB-158
                 URL: http://jira.jboss.com/jira/browse/JBESB-158
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: Documentation
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.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

        


From jira-events at jboss.com  Sat Sep 30 15:47:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:47:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-159) Refactor modules
Message-ID: <21094178.1159645661642.JavaMail.jira@cloud.prod.atl2.jboss.com>

Refactor modules
----------------

                 Key: JBESB-159
                 URL: http://jira.jboss.com/jira/browse/JBESB-159
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.1


Do we need 3 modules for the core ESB?

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:59:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-148) Glossary of terms
In-Reply-To: <28492607.1159188841189.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15034766.1159646381741.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-148?page=all ]

Mark Little closed JBESB-148.
-----------------------------

    Resolution: Duplicate Issue

> Glossary of terms
> -----------------
>
>                 Key: JBESB-148
>                 URL: http://jira.jboss.com/jira/browse/JBESB-148
>             Project: JBoss ESB
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Documentation
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>
> We need a glossary of terms in the documentation and/or wiki.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:59:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Commented: (JBESB-86) Identify what QA
 and unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27290196.1159646381857.JavaMail.jira@cloud.prod.atl2.jboss.com>

    [ http://jira.jboss.com/jira/browse/JBESB-86?page=comments#action_12344367 ] 
            
Mark Little commented on JBESB-86:
----------------------------------

We will start with automating the trailblazer into the QA and enable different configurations/deployments of it to test aspects of the system. From there we'll add new scenarios.

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 15:59:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 15:59:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-86) Identify what QA and
 unit tests we need for the GA release.
In-Reply-To: <3930599.1153214231518.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32935923.1159646382059.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-86?page=all ]

Mark Little closed JBESB-86.
----------------------------

    Resolution: Done

> Identify what QA and unit tests we need for the GA release.
> -----------------------------------------------------------
>
>                 Key: JBESB-86
>                 URL: http://jira.jboss.com/jira/browse/JBESB-86
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Testing
>    Affects Versions: 4.0 Beta 1, 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 4 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 16:35:42 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 16:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-118) Look at using the
 Property Manager from JBossTS/common
In-Reply-To: <27700242.1154946012291.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27001505.1159648542089.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-118?page=all ]

Mark Little closed JBESB-118.
-----------------------------

    Resolution: Done

> Look at using the Property Manager from JBossTS/common
> ------------------------------------------------------
>
>                 Key: JBESB-118
>                 URL: http://jira.jboss.com/jira/browse/JBESB-118
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>


-- 
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

        


From jira-events at jboss.com  Sat Sep 30 16:35:42 2006
From: jira-events at jboss.com (Roy Russo (JIRA))
Date: Sat, 30 Sep 2006 16:35:42 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (SWAP-17) Outline plan for
	project PBS
Message-ID: <21301483.1159648542238.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/SWAP-17?page=all ]

Roy Russo resolved SWAP-17.
---------------------------

    Fix Version/s: PortletSwap 2.0
       Resolution: Done

Moved to: https://prp.dev.java.net/

> Outline plan for project PBS
> ----------------------------
>
>                 Key: SWAP-17
>                 URL: http://jira.jboss.com/jira/browse/SWAP-17
>             Project: PortletSwap
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Infrastructure
>    Affects Versions: PortletSwap 2.0
>            Reporter: Roy Russo
>         Assigned To: Roy Russo
>             Fix For: PortletSwap 2.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

        


From jira-events at jboss.com  Sat Sep 30 16:45:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 16:45:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-140) Move samples out of
	docs
In-Reply-To: <19507011.1158670556332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20162596.1159649141768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-140?page=all ]

Mark Little reassigned JBESB-140:
---------------------------------

    Assignee: Mark Little  (was: Daniel Brum)

> Move samples out of docs
> ------------------------
>
>                 Key: JBESB-140
>                 URL: http://jira.jboss.com/jira/browse/JBESB-140
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core, Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>
> The trailblazer needs to be more prominent in the distribution and source. Let's move it out of the docs directory and into it's own, at the same level as docs.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 16:59:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Sat, 30 Sep 2006 16:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Reopened: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
In-Reply-To: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6508507.1159649981768.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1045?page=all ]

Boleslaw Dawidowicz reopened JBPORTAL-1045:
-------------------------------------------

             

> port OpenDS integration from JBoss AS testsuite to portal testsuite
> -------------------------------------------------------------------
>
>                 Key: JBPORTAL-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Test
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 3 hours, 16 minutes
>
> Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:02:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Sat, 30 Sep 2006 17:02:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Resolved: (JBPORTAL-1045) port OpenDS
 integration from JBoss AS testsuite to portal testsuite
In-Reply-To: <30172015.1158562490802.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3872190.1159650161502.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBPORTAL-1045?page=all ]

Boleslaw Dawidowicz resolved JBPORTAL-1045.
-------------------------------------------

    Resolution: Rejected

OpenDS is jdk5 dependant while portal need to be 1.4 compatible

> port OpenDS integration from JBoss AS testsuite to portal testsuite
> -------------------------------------------------------------------
>
>                 Key: JBPORTAL-1045
>                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1045
>             Project: JBoss Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Portal Test
>    Affects Versions: 2.6.Alpha1
>            Reporter: Boleslaw Dawidowicz
>         Assigned To: Boleslaw Dawidowicz
>             Fix For: 2.6.Alpha1
>
>          Time Spent: 2 days, 3 hours, 16 minutes
>
> Port work that Anil did in JBoss AS testsuite http://jira.jboss.com/jira/browse/SECURITY-5 to portal - integration of OpenDS for ldap testing

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:05:41 2006
From: jira-events at jboss.com (Boleslaw Dawidowicz (JIRA))
Date: Sat, 30 Sep 2006 17:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBPORTAL-1062) ApacheDS for
 ldap integration testing
Message-ID: <17861467.1159650341688.JavaMail.jira@cloud.prod.atl2.jboss.com>

ApacheDS for ldap integration testing
-------------------------------------

                 Key: JBPORTAL-1062
                 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1062
             Project: JBoss Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Portal Test
    Affects Versions: 2.6.Alpha1
            Reporter: Boleslaw Dawidowicz
         Assigned To: Boleslaw Dawidowicz
             Fix For: 2.6.Alpha1


- make embedded ApacheDS  service to use in testing framework

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:17:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:17:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-160) Unify config
	directories
Message-ID: <31047871.1159651061661.JavaMail.jira@cloud.prod.atl2.jboss.com>

Unify config directories
------------------------

                 Key: JBESB-160
                 URL: http://jira.jboss.com/jira/browse/JBESB-160
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


docs/Install/config and config? Why two?

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:20:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:20:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-140) Move samples out of
	docs
In-Reply-To: <19507011.1158670556332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10619071.1159651241622.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-140?page=all ]

Mark Little closed JBESB-140.
-----------------------------

    Resolution: Done

> Move samples out of docs
> ------------------------
>
>                 Key: JBESB-140
>                 URL: http://jira.jboss.com/jira/browse/JBESB-140
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Documentation, ESB Core, Examples
>    Affects Versions: 4.0 Beta 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>            Priority: Minor
>             Fix For: 4.0
>
>          Time Spent: 15 minutes
>  Remaining Estimate: 0 minutes
>
> The trailblazer needs to be more prominent in the distribution and source. Let's move it out of the docs directory and into it's own, at the same level as docs.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:23:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:23:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-161) Configuration is too
	confusing
Message-ID: <17897435.1159651421634.JavaMail.jira@cloud.prod.atl2.jboss.com>

Configuration is too confusing
------------------------------

                 Key: JBESB-161
                 URL: http://jira.jboss.com/jira/browse/JBESB-161
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
          Components: ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


Configuration information for the runtime system, for the object store, for the listeners and for the trailmap is far too confusing. We need one way of doing things. Use the PropertyManager for deployment configuration.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:26:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:26:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-162) Where possible,
 configure the trailmap using PropertyManager
Message-ID: <16179927.1159651601631.JavaMail.jira@cloud.prod.atl2.jboss.com>

Where possible, configure the trailmap using PropertyManager
------------------------------------------------------------

                 Key: JBESB-162
                 URL: http://jira.jboss.com/jira/browse/JBESB-162
             Project: JBoss ESB
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Daniel Brum
             Fix For: 4.0


Can we have a loanbroker XML configuration file and use the PropertyManager?

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:38:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:38:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Created: (JBESB-163) Install dir not
 copied into distribution
Message-ID: <11073750.1159652321519.JavaMail.jira@cloud.prod.atl2.jboss.com>

Install dir not copied into distribution
----------------------------------------

                 Key: JBESB-163
                 URL: http://jira.jboss.com/jira/browse/JBESB-163
             Project: JBoss ESB
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Distribution, Documentation, ESB Core
    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
            Reporter: Mark Little
         Assigned To: Mark Little
             Fix For: 4.0


The Install dir in docs is not copied into the distribution.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 17:59:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 17:59:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Closed: (JBESB-163) Install dir not
 copied into distribution
In-Reply-To: <11073750.1159652321519.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4391016.1159653581689.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-163?page=all ]

Mark Little closed JBESB-163.
-----------------------------

    Resolution: Done

> Install dir not copied into distribution
> ----------------------------------------
>
>                 Key: JBESB-163
>                 URL: http://jira.jboss.com/jira/browse/JBESB-163
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Distribution, ESB Core, Documentation
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Mark Little
>             Fix For: 4.0
>
>          Time Spent: 10 minutes
>  Remaining Estimate: 0 minutes
>
> The Install dir in docs is not copied into the distribution.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 18:05:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 18:05:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-104) Re-qualify against
	MQSeries
In-Reply-To: <23337772.1154437031460.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4784320.1159653941778.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-104?page=all ]

Mark Little reassigned JBESB-104:
---------------------------------

    Assignee: Kurt Stam  (was: Kevin Conner)

> Re-qualify against MQSeries
> ---------------------------
>
>                 Key: JBESB-104
>                 URL: http://jira.jboss.com/jira/browse/JBESB-104
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Alpha 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>            Priority: Blocker
>             Fix For: 4.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

        


From jira-events at jboss.com  Sat Sep 30 18:08:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 18:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-150) There are too many
 magic numbers/strings in the code
In-Reply-To: <2024480.1159360722469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6792639.1159654121715.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-150?page=all ]

Mark Little reassigned JBESB-150:
---------------------------------

    Assignee: Kurt Stam  (was: Mark Little)

> There are too many magic numbers/strings in the code
> ----------------------------------------------------
>
>                 Key: JBESB-150
>                 URL: http://jira.jboss.com/jira/browse/JBESB-150
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.0
>
>
> Particularly in the property space.

-- 
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

        


From jira-events at jboss.com  Sat Sep 30 18:08:41 2006
From: jira-events at jboss.com (Mark Little (JIRA))
Date: Sat, 30 Sep 2006 18:08:41 -0400 (EDT)
Subject: [jboss-jira] [JBoss JIRA] Assigned: (JBESB-153) Make all
 configuration attribute names have consistent format
In-Reply-To: <25928255.1159443281619.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18273696.1159654121947.JavaMail.jira@cloud.prod.atl2.jboss.com>

     [ http://jira.jboss.com/jira/browse/JBESB-153?page=all ]

Mark Little reassigned JBESB-153:
---------------------------------

    Assignee: Kurt Stam  (was: Mark Little)

> Make all configuration attribute names have consistent format
> -------------------------------------------------------------
>
>                 Key: JBESB-153
>                 URL: http://jira.jboss.com/jira/browse/JBESB-153
>             Project: JBoss ESB
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: ESB Core
>    Affects Versions: 4.0 Beta 1 Maintenance Pack 1
>            Reporter: Mark Little
>         Assigned To: Kurt Stam
>             Fix For: 4.0
>
>
> org.jboss.soa.esb as the root of all names.

-- 
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

        


